2.3 Культура коду програми

     Для розробника програм найціннішим ресурсом є час. Одна хвилина, витрачена на написання коментарів, здатна позбавити вас від тривалих мук.

     Код гарної програми повинен бути на стільки простим, на скільки це можливо. "Не треба ускладнювати завдання", "Keep it simple, stupid! (Правило KISS)","вибирайте найпростіше з працюючих рішень","не треба робити того, що не передбачено технічним завданням", будьте простіші!

     Простий код простіший у читанні, а значить у підтримці. Простий код зазвичай коротше і зрозуміліше, а значить, містить менше помилок.

     Виникає неминуче питання - як зробити таким чином, щоб програмний код був зрозумілим, не створював складнощів при подальшому супроводі й взагалі не являв собою нерозбірливу плутанину?

     Будьте розсудливі - пишіть коментарі.

     Коментуйте свій програмний код. Обов'язково. Наприклад, ви написали процедуру і не супроводили її коментарями. Коли ви через кілька місяців повернетеся до неї для доопрацювання (а вам напевно доведеться це зробити), відсутність коментарів призведе до додаткових втрат робочого часу. Втрачений час неможливо компенсувати.

     Слід, однак, відзначити, що написання коментарів - це теж мистецтво. Для досягнення майстерності у цьому виді діяльності необхідна практика. Коментарі бувають хороші й погані.

     Не треба писати занадто довгих коментарів. З іншого боку, не слід писати дуже коротких коментарів. І, нарешті, не слід писати дурних коментарів.

     Коментарі не тільки економлять час, вони самі потребують часу. Коментарі вимагають часу на прочитання, крім того, вони збільшують фактичні розміри програми на екрані монітора, в результаті чого перед вашими очима може одночасно перебувати менший обсяг діючого програмного коду.

     Не давайте змінним імена, здатні ввести в оману [11].

     Кінцева мета проста: написати програмний код таким чином, щоб стороння людина, не маюча уявлення про те, що цей код робить, могла зрозуміти його якомога швидше.

     Один з основних способів досягнення цієї мети полягає у тому, щоб давати змінним, процедурам тощо хороші, так звані "говорячі" імена. Якщо згаданий вище гіпотетичний читач вашого коду, подивившись на ім'я змінної, подумає: "Ага, я розумію, що це таке", це заощадить йому п'ять хвилин - йому не доведеться переглядати вашу програму на предмет пояснень, що, врешті-решт, на думку автора коду має означати ім'я тієї чи іншої змінної.

     При цьому необхідно дотримуватися золотої середини. Давайте своїм об'єктам імена, досить довгі й наочні для розуміння їх сенсу, однак не настільки довгі й громіздкі, щоб це ускладнювало читання програмного коду.

     Перевіряйте свою програму на наявність помилок.

     Якщо ваша програма досить велика, в ній напевно буде безліч функцій і процедур. Як би це не здавалося клопітно, кожну функцію/процедуру необхідно перевіряти на наявність помилок. Напишіть свій код так, щоб він перевіряв процедуру/функцію на наявність ворожих даних і захищався від них.

     Переваги такого підходу не вичерпуються захистом програми від збоїв. Хороші механізми перевірки на наявність помилок також прискорюють налагодження. Припустимо, ви дізналися, що десь відбувається запис даних за межами деякого масиву, і переглядаєте свій код у пошуках місця, де це може відбуватися. Якщо в якій-небудь процедурі наявні всі механізми перевірки, вам не доведеться проходити її крок за кроком у пошуках помилки.

     "Передчасна оптимізація - корінь усіх негараздів", - Дональд Кнут (Donald Knuth).

     Якщо ваша кінцева мета не полягає у тому, щоб мучити людей, то при написанні програмного коду, варто прагнути максимальної зрозумілості. Простий код вимагає менше часу на написання, на розуміння при наступному звертанні до нього і до налагодження.

     Оптимізація - ворог ясності. Слід, однак, відзначити, що у деяких випадках оптимізація необхідна. Це особливо справедливо для ігор. Проте - і це дуже важливо - майже ніколи не відомо заздалегідь, що саме необхідно оптимізувати, до тих пір, поки ви не протестуєте реально функціонуючий код за допомогою інструменту під назвою профайлер.

Профайлер - це програма, яка спостерігає за вашою програмою і оцінює час, що витрачається на виконання окремих викликів. Існують чудові програми цього типу.     Напишіть ясну і працюючу програму. Згодом у вас буде достатньо часу, щоб спаплюжити її за допомогою оптимізації. Однак не робіть цього до тих пір, поки не будете абсолютно впевнені, що робите правильно.

     Не мудрувати.

     За наявності достатніх знань ви зможете втиснути десять рядків нормального коду в один рядок. Ціна за це буде невисокою - усього лише повна неможливість швидко виправити помилку в цьому коді. Якщо створюваний код вимагає від вас детального знання хитромудрих правил пріоритету або змушує вас заглядати в останні глави будь-якої книги, щоб зрозуміти, що саме ви робите - це означає, що ви почали мудрувати.

     Прагніть до простоти і ясності - це збереже вам масу часу і позбавить від непотрібних страждань. Ще раз повторимо, що код гарної програми повинен бути на стільки простим, на скільки це можливо. "Не треба ускладнювати завдання", "Keep it simple, stupid! (Правило KISS)","вибирайте найпростіше з працюючих рішень","не треба робити того, що не передбачено технічним завданням", будьте простіше!

     На що ще слід звертати увагу.

     Довжина рядка не повинна перевищувати 80 символів. Зазвичай доводиться переносити або виклики функцій з великою кількістю аргументів, або які-небудь складні умови в конструкціях типу if. Але переносити треба обов'язково, так, щоб весь код було видно без прокручування екрану по горизонталі.

     Використовуйте табуляцію замість пробілів. Бажано користуватися саме табом, замість пробілів. Це і швидше (табуляція зазвичай відповідає кільком прогалинам), і зручніше для редагування, коли потрібно, наприклад, зрушити код вліво. У багатьох середовищах програмування в тулбарі є кнопки для зсуву вліво або вправо блоків коду. Досить виділити потрібний шматок коду і натиснути на відповідний значок.

     Слідкуйте за правильною кількістю відступів усередині всіх конструкцій. Кількість табуляцій перед кодом повинно відповідати його вкладеності. Багато середовищ програмування зараз автоматично вирівнюють код, але не всі, так що стежити треба самому.

     Функція повинна вміщуватися на екран. Це, звичайно, в ідеалі, але дуже бажано. Якщо розмір функції складає більше двох екранів - це явна ознака того, що її має сенс розділити на кілька частин. Коли починаєш програмувати якесь завдання, часто буває, що немає бажання відволікатися на усілякі дрібниці, наприклад, винести в окрему функцію запис логів і т.п. У результаті кожна функція вихідного коду крім вирішення своїх основних завдань, містить ще купу рядків лівої функціональності, яким тут просто не місце.

     Варто зазначити, що бувають винятки. Наприклад, якщо у функції є оператор switch, то вона може бути досить громіздкою.

     Використовуйте "говорячі" назви функцій та змінних. Відмовтеся від змінних типу kkk, або функцій на зразок gdfui(), краще введіть довгу назву getDoubleFromUnsignedInt(), зате відразу буде ясно, що відбувається. При певному розмірі програми використання "не говорячих" функцій і змінних взагалі унеможливить будь-яку подальшу розробку.

     Відмовтеся від неоднозначних і безглуздих назв. Деякі дієслова можуть описувати практично будь-які дії всередині функцій. Наприклад, Calculation(), HandleInput() або ProcessData(). З одного боку, назва функції може узгоджуватися з вмістом, але здогадатися про вміст за назвою практично неможливо. Тому замість Calculation() потрібно писати щось більш докладне, типу GetSolutionOfEquation().

     Не використовуйте нумерацію для функцій, які вирішують схожі завдання. Буває, що функції виконують одне і те ж, але різними способами. Наприклад, ми хочемо написати функцію факторіала і реалізували два варіанти - за допомогою циклу і за допомогою рекурсії. Не потрібно називати функції Fact1() і Fact2(). Дайте більш осмислені назви FactCicle() і FactRecursion().

     Не намагайтеся штучно обмежити довжину імені функції. Згідно з дослідженнями оптимальна довжина змінної - це 9-15 символів. Функція, як ви розумієте, несе ще велике смислове навантаження, відповідно і довжина у неї може бути ще більшою. Важливо мати "говорячі" назви функцій, а не певну довжину.

     Не використовуйте як імена функцій російські слова, написані транслітом. Назви типу risuemKrug() непривабливі, на відміну від drawCircle(), наприклад. Назви з використанням англійських слів будуть нормально сприйняті будь-яким програмістом, на відміну від використання русіш неймінг.

     Використовуйте опис значення, що повертається для іменування функції. Якщо функція щось повертає, це повинно бути зрозуміло з назви. Приклад хороших імен: sin(), GetMaxValue(), monitor.IsReady(), iteratorNextElement().

     Рефакторинг.

     Рефакторинг - це процес зміни коду без зміни функціональності. Тобто з точки зору користувача програма не змінюється. Але з точки зору програміста вона змінюється, при чому у бік покращення, якщо рефакторинг проводиться грамотно.

     Рефакторинг полягає в чищенні програмного коду від латочок, милиць, "хаков" тощо і зміни архітектури з метою зробити її більш зрозумілою, гнучкою. Подібну чистку необхідно проводити регулярно. Це зробить код більш простим, надійним, гнучким. Якщо ви не знайомі з шаблонами проектування, то можна з ними ознайомитися, виявити ті, які застосовні у вас і переписати додаток з використанням вибраних шаблонів.

     Іншим кандидатом на рефакторинг є код, який писався без попереднього проектування або при неповному розумінні завдання. Отримавши досвід вирішення задачі, ви зможете зробити ваш код більш якісним. Код який кілька разів переписувався або змінювався швидкоруч, так само може вимагати рефакторингу. Відразу написати ідеальний код - це дуже складне завдання. Код повинен еволюціонувати, і в цьому вам допоможе рефакторинг.

     Рефакторинг необхідний, якщо:

1. Має місце складність модифікації. Підтримка вимагає все більше і більше ресурсів.

2. Має місце складність читання. Є коментарі типу: "Як це працює - не зрозуміло. Не чіпай!".

     Перш ніж приступити до рефакторингу підготуйте засіб підтвердження коректності коду.