При створенні програмного продукту розробник:
- читає код;
- змінює код;
- запускає на виконання і виявляє помилки.
Чим швидше розробник буде виконувати ці завдання, тим швидше він зможе випустити чергову версію продукту, тим динамічніше розвиватиметься його кар'єра. Тому код має задовольняти такі вимоги:
- код легко читати і сприймати;
- код легко змінювати;
- код можна повторно використати і тестувати;
- код використовує безкоштовні платформу і ПЗ;
- мінімальне використання ресурсів;
- стабільність при зміні конфігурації / середовища.
Щоб отримати якісний код, достатньо дотримуватися таких правил:
1. Дотримуватися стандартів оформлення коду. У кожної мови програмування є свій стандарт оформлення коду: які і де робити відступи (зазвичай 2 або 4 на один рівень вкладення), де ставити прогалини і дужки, як називати об'єкти, як коментувати код тощо — див. посилання для C# (1, 2), C++ (1, 2, 3), Java, Javascript (1, 2, 3), Pascal / Delphi, Perl, PHP, Python, Ruby. Деякі організації (наприклад, Google) підлаштовують (змінюють, деталізують) стандарти під свої специфічні потреби. Стандарти можуть містити налаштування редактора коду, які допоможуть дотримуватися відповідного стилю.
2. Надавати змістовні назви змінним, функціям і методам. Інакше кажучи, вперше прочитавши код стороння людина має зрозуміти призначення змінної, функції або методу.
Невдалий щодо назв код:
const fnm = 'Tom';
const lnm = 'Hanks';
const x = 31;
const l = lstnm.length;
const boo = false;
const curr = true;
const sfn = ‘Remember the name’;
const dbl = [‘1984’, ‘1987’].map((i) => {return i * 2;});
Кращий код:
const firstName = 'Tom';
const lastName = 'Hanks';
const age = 31;
const lastNameLength = lastName.length;
const isComplete = false;
const isCurrentlyActive = true;
const songFileName = ‘Remember the name’;
const yearsDoubled = [‘1984’, ‘1987’].map((year) => {return year * 2;});
3. Писати читабельний код, який можна однаково легко зрозуміти, незалежно від того, який обсяг цього коду розглядають.
Наскільки читабельність інтуїтивна? Її можна досягти, якщо дотримуватися деяких правил та угод? Маємо кілька рекомендацій:
Наскільки читабельність інтуїтивна? Її можна досягти, якщо дотримуватися деяких правил та угод? Маємо кілька рекомендацій:
o cкладні для сприйняття методи мають бути короткими, а прості методи можуть бути довгими;
o уникати вкладених циклів і примусового виходу з циклу, де це можливо;
o намагатися записувати кожен вираз (вказівку) окремим рядком;
o уникати надмірної кількості методів, що послідовно викликають один за одним.
4. Будь-яка функція або метод мають виконували лише одну задачу (принцип поділу обов'язків) — див. приклад розмежування арифметичних операцій.
function subtract(x, y) {
return x - y;
}
function multiply(x, y) {
return x * y;
}
function doubleArray(array) {
return array.map(number => number * 2)
}
5. Використовувати коментарі для пояснень того, що даний метод (процедура) робить, параметрів, значення, що повертають, можливих помилок і виключень. Описати в коментарях роль кожного файлу і класу, вміст кожного поля класу і основні кроки складного коду. Писати коментарі у процесі створення коду, а не після створення. Коментарі мають описувати мету частини коду, а не механізм того, як її досягти. Інакше кажучи, описувати «навіщо», а не «як». При використанні у коментарях назв змінних краще зупинитися і переписати коментар.
Не правильно:
countryCode = GetCountryCode(ServerType.BackUp); // Отримати код
if (countryCode == “US”) // Якщо код US
InvokeUSUser(); // Показати користувача
Правильно:
// Показати користувачів з US
countryCode = GetCountryCode(ServerType.BackUp);
if (countryCode == “US”)
InvokeUSUser();
6. Стисло писати код — див. приклад використання колекції для спрощення коду при створенні списку з одного елемента.
public static List<String> toList(String item) {
List<String> items= new ArrayList<>();
items.add(item);
return items;
}
Компактніше це записують так:
public static List<String> toList(String item) {
return Collections.singletonList(item);
}
7. Уникати глибоких вкладень, які ускладнюють сприйняття коду і виявлення помилок.
Не правильно:
public int DoSmth(){
if (IsWritable(folder)) {
if (fp == FileOpen(filePath,”w”)) {
if (stuff = getSomeStuff()) {
if (FileWrite(filePath,stuff)){ // ..
Правильно:
public int DoSmth(){
if (!IsWritable(folder))
{
return false;
}
if (fp != FileOpen(filePath, “w”))
{
return false;
}
if (stuff != getSomeStuff())
{
return false;
}
if (!FileWrite(filePath, stuff))
{ //..
}
else return false;
}
8. Розділяти код на короткі частини. Код кожного методу, функції чи блоку має не виходити за межі вікна (25−50 рядків). Інакше його потрібно поділити на коротші частини. Хоча б порожніми рядками. Призначення кожного блоку бажано описати у коментарі на початку кожного блоку. Якщо частини коду виконують різнорідні завдання, то його потрібно розділити відповідним чином.
9. Використовувати тестування частинами (Unit-тести). Складність сучасного програмного забезпечення робить його створення дорожче, а тестування важче. Продуктивним підходом буде супровід кожної частини коду тестами, які перевіряють правильність саме його роботи. Цей підхід спрощує налагодження, бо дозволяє виявити помилки раніше. Unit-тестування особливо необхідно, коли програмують інтерпретованою мовою з динамічною типізацією (наприклад, JavaScript, Python чи Ruby), бо у цьому випадку можна виявити будь-які помилки лише на етапі виконання. Для мови зі статичною типізацією (наприклад C#, C++ чи Java) частину помилок можна виявити під час компіляції.
Домашнє завдання опрацювати опорний конспект.
Немає коментарів:
Дописати коментар