Як написати чистий код

Зробити код чистим і красивим — чудовий спосіб встигати до дедлайну Роберт Мартін потрапив у крапку з одним своїм ємним висловом: «Єдиним вірним показником вимірювання якості коду є одиниця «Якого чорта/хвабону» (або «What-The-F**ks/Minute " в оригіналі). Дозвольте мені пояснити, що це означає. Щоразу, коли я роблю огляд коду, мій мозок відтворює одну з трьох емоцій:

• "WTF?!" Якого біса?!" (з огидою) - це не те ... все дуже погано.
• "WTF?!" Якого біса?!" (З захопленням) - хм, це робив кмітливий хлопець!
• "WTF?!" Якого біса?!" (з роздратуванням) — якась плутанина, про що тут взагалі мова?!

То що є першорядним і що саме ми оцінюємо, коли нам на очі потрапляє якийсь код? Ось що: його чистота та краса. Вміння писати чистий та красивий код – показник високого професіоналізму розробника. Навчання цій майстерності ґрунтується на двох складових — це знання та робота. Знання навчають вас патернам, принципам, практикам, евристиці. Ви потребуєте їх рости професійно. Тільки ці знання ви повинні вбирати, як губка, шляхом постійної практики і старанної роботи. Якщо говорити коротко, то писати чистий код – це не так просто. Це важка копітка робота, і над нею доведеться попітніти. Методом спроб і помилок ви удосконалюватиметеся, повторюючи ті ж кроки знову і знову, поки не знайдете бажане рішення. Простішого шляху просто не існує. Нижче наведено деякі підказки, які допоможуть вам навчитися писати чистий код.

Що в імені тобі моєму

Кендрік Ламар (Kendrick Lamar, американський хіп-хоп виконавець, — прим. ред.) одного разу точно помітив: «Якщо я збираюся розповісти реальну історію, то маю почати зі свого імені». Імена у розробці програмного забезпечення всюди. Ми називаємо функції, класи, аргументи, пакети, програми все, що завгодно. Ми називаємо вихідні файли та довідники і все з цим пов'язане. Ми нескінченно щось називаємо і це стає найважливішою частиною роботи над створенням чистого коду. Ім'я, яке ви даєте чомусь, має відображати намір. Знайти хороше ім'я непросто, це вимагає часу, але й значно заощаджує його, коли доводиться розбиратися з кодом та ситуація стає складною. Тому поставтеся до цього процесу уважно і не бійтеся міняти імена пізніше, якщо вам вдалося знайти найкраще. Усі, хто матиме справу з вашим кодом, будуть вам дуже вдячні.

"Одна функція" - одна річ

Луїс Салліван (Louis Henry Sullivan, американський архітектор-раціоналіст і модерніст) якось чудово сказав: “функція визначає форму” . Говорив він це про архітектуру будинків, але суті це не змінює. Кожна система будується якоюсь предметно-орієнтованою мовою, яку створюють програмісти, щоб точно її описати. Функції виконують роль дієслів цієї мови, а класи - це іменники. Найчастіше функції є першорядними у створенні мови програмування, і грамотне їх написання є суттю створення хорошого коду. Є лише два золоті правила якісного написання функцій:

1. Вони мають бути невеликими
2. Вони повинні виконувати щось одне, одне завдання, і робити це добре

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

"Коментарі не компенсують поганий код"

Вінус Вільямс (Venus Williams, американська тенісистка, п'ятиразова переможниця турніру Вімблдону) потрапила в крапку, сказавши: «Всі залишають свої коментарі. Так і з'являються чутки». Коментарі - це як гострий меч. Залишений до місця коментар - дуже корисна штука. З іншого боку, ніщо так не захаращує простір, як фривольні, марні коментарі. Але найбільш згубними є коментарі, які розповсюджують дезінформацію та брехню. Коротше кажучи, коментарі — це своєрідне зло. Не завжди, але здебільшого. Чому? Все просто, чим старший коментар, тим складніше його підтримувати, і більшість програмістів, як ви знаєте, далеко не завжди змінюють коментарі разом зі змінами в коді. Код рухається та розвивається. Частини коду переміщуються сюди-туди, а коментарі немає. І це стає проблемою!

"Форматування коду - завжди в пріоритеті"

Це сказав не хто інший, як Роберт С. Мартін (Robert Cecil Martin), він же - дядько Боб, розробник, автор безлічі книг з розробки програмного забезпечення, консультант, співавтор маніфесту Agile і так далі. І додав: «Форматування коду — це своєрідна комунікація. А комунікація — це першочергове завдання будь-якого професійного розробника». Наведене вище твердження не можна недооцінювати, адже воно говорить про одну з найважливіших характеристик відмінного розробника. Відформатований код дозволяє глянути вглиб вашої свідомості. Ми хочемо вразити людей своєю акуратністю, увагою до деталей, умінням упорядкувати та чітко висловлювати свої думки. Але якщо, дивлячись на код, люди бачать якусь плутанину, що нагадує вінегрет, що не має ні початку, ні кінця, це зводить нанівець ваші старання та знижує репутацію розробника. Навіть не сумнівайтесь у цьому! Ви дуже далекі від істини, якщо вважаєте, що головне в цьому бізнесі, щоб “код просто працював”. Функціональність, яку ви сьогодні створюєте, з високою ймовірністю буде змінена в наступному релізі. А ось читаність коду не зміниться. Стиль коду та його хороша читаність полегшують підтримку коду на довгий час,

Спочатку створіть блок "try-catch-finally"

Жорж Кангілем (Georges Canguilhem, історик науки, філософ) справедливо зазначив: "Помилятися - природно для людини, але наполягати на помилках - це від диявола". Робота над помилками – це те, що роблять усі програмісти. На вхід можуть потрапити невірні дані та пристрої можуть виходити з ладу. І, як розробники, ми повинні переконатися, що код робить те, що має. Питання полягає не просто в обробці помилки, а в її "чистій обробці, що легко читається". Багато програм підлаштовуються під обробку помилок. Якщо так чинити, все поринає в такий хаос, що знищується мета та логіка основного коду. Це неправильно, так не має бути. Код повинен бути чистим і надійним, а обробка помилок має спокійно та природно вплітатися у цей код. Це показник високого класу програміста. І один із способів досягти цього — це правильні вкладення та охоплення всіх помилок у блоках try-catch. Ці блоки визначають рамки застосування коду. Коли ви виконуєте код у try-частині блоку try-catch-finally, ви стверджуєте, що це виконання може обірватись у будь-який момент часу, а потім відновитись у catch. Тому рекомендуємо починати з try-catch-finally, коли ви пишете код. Це допоможе визначити, що може очікувати від коду користувач, незалежно від того, що код піде не так під час роботи try.

Підведемо підсумки

Підсумувати все вищесказане нам допоможе одне незвичне словосполучення. Це code-sense або "чуття здорового коду", такий собі програмістський еквівалент здорового глузду. За словами Роберта Мартіна: «Написання чистого коду вимагає систематичного використання безлічі маленьких прийомів, які застосовуються в результаті скрупульозного та дещо болючого почуття «чистоти». Ці невеликі прийоми разом називаються code-sense». У деяких з нас це “чуття здорового коду” є спочатку, іншим доводиться розвивати його виявляючи наполегливість у практиці. Це чуття допомагає не просто розпізнати різницю між поганим і добрим кодом, а й допомагає у формуванні стратегій, націлених на трансформацію поганого коду в добрий. Поганий код псує все. Якщо говорити образно, то якщо найсмачніший торт глазурує собачим лайном, то...еее... навряд чи він комусь сподобається. Чуття здорового коду допомагає програмісту використовувати потрібні інструменти для досягнення своєї мети - створення чистого коду. Програміст, який розуміє, що таке code-sense — це художник, здатний на порожньому екрані створити витвір мистецтва, який запам'ятається на довгі роки. Як підсумував Гарольд Абельсон (Harold «Hal» Abelson, професор комп'ютерних наук у Mit,«Насамперед програми потрібно писати так, щоб їх могла прочитати людина, і вже потім — щоб їх виконувала машина» . Що можна почитати на тему: "A handbook of Agile Software Craftsmanship" - Robert Martin. "A handbook of Agile estimation" - Mike Cohn Про автора: Раві Шанкар Раджан (Ravi Shankar Rajan) - Global Manager IT-програм з Мумбаї (Індія). Відомий блогер, поет хокку, затятий любитель археології та історії. Зв'язатися з ним можна в Twitter , Medium , LinkedIn