Правила книги “Чистий код” 6 для оптимального найменування
Фаб'єн, Веб-розробник 28 серпня 2019 р
Книгу розробників Clean Code (або Clean Code у вихідній версії) написав Роберт К. Мартін. Професійним розробником з 1970 року, він також став міжнародним консультантом з програмного забезпечення в 1990 році. Щоб написати цю книгу, автор оточив себе командою досвідчених розробників, щоб поділитися передовим досвідом роботи з кодом.
Таким чином, метою книги «Чистий кодекс» є набуття основ хорошого коду та розуміння переваг, які він забезпечує. Він дає ключі для перетворення поганого коду в хороший код.
Ця стаття є першим оглядом книги Роберта К. Мартіна. В основному ми повертаємось до першої частини «Іменування». Автор дає визначення того, що він вважає хорошим кодом. Ця частина також стосується труднощів іменування об’єктів та змінних при розробці комп’ютера.
Важливо витратити час на добре кодування
Коли "пізніше" означає "ніколи"
У програмі Coder Proprement автор повертається до'' одна з головних перешкод на шляху до хорошого коду: відчуття нестачі часу. Однак недбалий код - саме джерело неминучої втрати часу в більш-менш довгостроковій перспективі.
Часто, коли у нас не вистачає часу, ми думаємо, що повернемося пізніше, щоб очистити чи виправити поганий код. Але чи справді ви думаєте, що згодом знайдете більше часу? ?
Дейв Леблан висловлює свою думку у своєму законі Леблана: «Пізніше ніколи не означає”(З англійської пізніше Equals Never). Дійсно, зволікання часто зводиться до того, щоб ніколи не закінчити належним чином свою роботу, занадто зайняту новими місіями. Тому важливо бути оптимально організованими, щоб присвятити своєму коду час, який він заслуговує, у потрібний час.
Залиште код чистішим, ніж ви його знайшли
Інша цитата пристосовує правило хлопчиків, щоб перетворити його на хороше ескізне правило: "Залиште кемпінг чистішим, ніж ви знайшли його, коли прибули". СТАЄ "Залиште код чистішим, ніж ви його знайшли."
Дійсно, якщо кожен з них робить код трохи чистішим, ніж той, що був відновлений, код не можна погіршити. Просте очищення іноді може бути дуже корисним. Перейменування змінної, розділення функції або видалення невеликої надмірності може, наприклад, поліпшити якість коду.
Правильно називати елементи коду
Перша частина книги стосується повторюваної проблеми, добре відомої розробникам: іменування змінних, класів, функцій тощо. Однак у кожного розробника є своє визначення гарного коду. Іноді важко знайти абсолютну істину про те, що таке "Добрий кодекс".
Автор спирається тут на свій досвід, щоб передати власне бачення передових практик, особливо щодо імен.
Ось список 6 правил, запропонованих у книзі для оптимального іменування.
1. Розкрийте свої наміри в назві
За словами Роберта К. Мартіна, першим правилом використання імен є використання імені, яке виявляє наміри. Ця назва повинна повідомляти про її призначення, місію та використання.
У наведеному вище прикладі назва не дає поняття про корисність змінної. Використовуючи коментар, слід було попередити розробника про те, що назва невідповідна.
Ще один приклад простого, але незрозумілого лікування:
Тоді як при простому використанні імен той самий код стає цілком зрозумілим:
2. Уникайте імен, які дають погану інформацію
Правило №2: уникайте імен, які дезінформують про використання:
- уникайте помилкових підказок, наданих іменуванням, як абревіатура, яка може мати кілька значень (наприклад, hp для гіпотенузи)
- уникайте повторення типу змінної в назві (AccountList, хоча змінна не є списком)
- уникайте використання надто близьких імен (XYZControllerForEfficientHandlingOfStrings та XYZControllerForEfficientStorageOfStrings)
3. Використовуйте відмінні імена
Використання майже подібних назв також ускладнює розуміння коду. Якщо ім’я вже використовується, уникайте створення варіанту з орфографічною помилкою або цифрою (a1, a2). Наприклад:
У цьому випадку, якби "a1" було названо "джерелом", а "a2" - "призначенням", читабельність була б набагато кращою.
Це також кращеуникайте помилкових слів без значення, таких як Дані, Інформація (ProductInfo та ProductData, чим вони відрізняються?), змінна або тип даних (nameString, хоча name явно говорить про те, що очікується як тип даних).
Ми також можемо відзначити ці інші поради щодо іменування:
- Виберіть вимовні імена: простіше говорити між розробниками
- Виберіть імена, сумісні з пошуком: ім'я константи (MAX_CONTACTS_PER_LIST) легше знайти, ніж її значення (50)
- Уникайте кодифікації: наприклад уникати:
- вкажіть тип в імені, phoneString, тоді як змінна тепер має номер типу
- повторіть букву I у IShapeFactory, щоб вказати, що це інтерфейс
- Виберіть слово за концепцією: ми очікуємо мати однаковий принцип для класів з однаковим суфіксом
- Не соромтеся використовувати технічні терміни (якщо вони є частиною культури розробника) та використовувати торгові умови (якщо немає комп’ютерного терміну про те, що робиться).
4. Присвоєння класів імен
Щодо занять, автор пропонує розробникам вибрати імена або іменні групи, такі як Клієнт, ZipcodeParser. Він радить уникати таких термінів, як менеджер, обробник, дані чи інформація. Назва класу не повинна бути дієсловом.
5. Назвіть методи з дієсловами
Найкраща практика методів іменування - вибір дієслів чи дієслівних груп. Наприклад: postArticle, deleteArticle, save, getContact.
- Аксесуари, мутатори та предикати повинні бути названі відповідно до мовного стандарту (часто getX, setX або isX)
- У разі перевантаження виробника це було б необхідно використовувати статичні фабричні методи зі значущим ім'ям про те, що має бути вказано як параметр
Ви можете змусити використовувати виклик заводського методу, зробивши конструктор приватним.
6. Опишіть побічні ефекти
Імена повинні описувати все, що робить функція, навіть якщо це означає введення декількох дієслів у назву функції:
Наприклад, натомість цю функцію слід називати "CreateOrReturnInstance " оскільки він не тільки повертає Екземпляр, але й створює його.
Висновок: хороше іменування, основа хорошого коду
Перейменування часто страшне, оскільки може спричинити багато змін. Однак це завдання значно спрощується завдяки інструментам рефакторингу останніх IDE.
Зрештою, іменування - це не технічна навичка, а швидше здатність правильно описувати та ділитися зробленим. Дотримання цього набору правил іменування покращить читабельність коду та допоможе під час технічного обслуговування чи еволюції.