Зміст чистого коду та ключові моменти - DZone DevOps

Давним-давно я використав цей короткий зміст деяких ключових моментів, які зробив для вивчення книги «Чистий код». Сподіваюся, це допомагає іншим.

Приєднуйтесь до спільноти DZone та отримуйте досвід повного членства.

чистого

Давним-давно я використав цей короткий зміст деяких ключових моментів, які зробив для вивчення книги «Чистий код». Сподіваюся, це допомагає іншим. (Примітка: цей короткий зміст не виключає необхідності читати книгу.)

Що таке чистий код?

Код можна виміряти як "хорошим", так і "поганим" в огляді коду або тим, скільки хвилин вам потрібно, щоб поговорити про це.

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

Ви повинні додати цінності бізнесу за допомогою свого коду.

Чистий код пропонує якість та розуміння, коли ми відкриваємо клас.

Потрібно, щоб ваш код був чистим і читабельним, щоб його хтось міг знайти та легко зрозуміти. Уникайте витрачати час інших.

Значущі імена

Назви класів, змінних та методів повинні бути значущими і чітко вказувати, що робить метод або що таке атрибут.

Створіть вимовні імена для полегшення спілкування.

Уникайте скорочень та уникайте плутанини назв, що може призвести до помилкових висновків тих, хто читає код.

Використовуйте імена, що відображають системний домен, контекст та проблеми, які необхідно вирішити.

Функції

Метод повинен бути легким для читання та розуміння.

Метод повинен передати свій намір.

Методи повинні бути невеликими. Іншим правилом для малих методів є те, що вони повинні бути ще нижчими.

Вони повинні мати до 20 рядків. (Я думаю, вони повинні мати до 10 рядків.)

Методи повинні робити лише одне: вони повинні робити це правильно і просто робити це.

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

Оптимальна кількість параметрів методу дорівнює нулю, після одного і двох.

Треба уникати трьох, але якщо ви вважаєте, що їх слід використовувати, майте вагоме обґрунтування.

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

Методи повинні щось робити і щось повертати.

Коментарі

Однією з найпоширеніших причин для коментарів є те, що код поганий.

Якщо ви думаєте про те, щоб написати коментар, тоді код слід змінити.

Коментарі не зберігають поганий код.

Спробуйте пояснити, що викликає код.

Коментарі можуть бути корисними при розміщенні в певних місцях.

Створюйте імена методів та інформативні змінні замість того, щоб пояснювати код коментарями.

Коментарі можуть бути використані для вираження важливості певних пунктів коду.

Найкращий коментар - це той, який потрібно написати, оскільки ваш код уже пояснений.

Не пишіть коментарі із зайвою, марною або неправдивою інформацією.

Вони не повинні використовуватися для вказівки, хто змінив чи чому, оскільки це вже існує у версії.

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

Форматування

Форматування повинно вказувати на важливі речі, оскільки це розробник форми спілкування.

Брудний код важко прочитати.

Читаність коду набуде чинності при внесенні всіх змін.

Спробуйте написати клас із максимум 500 рядків. Менші класи легше зрозуміти.

Встановіть обмеження кількості символів на рядок коду.

Хороший ліміт символів для рядка - 120.

Спробуйте зберегти більше наступних пов'язаних понять вертикально, щоб створити потік коду.

Використовуйте пробіли між операторами, параметрами та комами.

Об'єкти та структура даних

Дотримуйтесь закону Деметри, який говорить, що один М-метод об'єкта O може споживати послуги лише таких типів об'єктів:

  • Сам об’єкт, О.
  • М параметри.
  • Будь-який об’єкт, створений або створений за допомогою М.
  • Прямі компоненти O.

Зробіть хорошу абстракцію та інкапсуляцію.

Не робіть німі предмети.

Об'єкти приховують абстракцію даних і виставляють методи, що керують даними.

Структури даних відкривають ваші дані і не мають значущих методів.

Обробка помилок

Всі програмісти повинні ретельно планувати обробку помилок.

Коли трапляються неправильні речі, ми повинні змусити це робити правильні речі.

Ми повинні віддавати перевагу запуску винятку, ніж обробці його просто для приховування.

Створюйте повідомлення з інформацією про помилку.

Згадайте, що це не вдалося. Де була ця невдача? Якщо можливо, згадайте, чому це не вдалося.

Подивіться на окремі бізнес-правила щодо помилок та обробки помилок.

Уникайте повернення NULL у методах, бажано повернути порожній об'єкт.

Уникайте передавання NULL методам; це може генерувати NullPointerExceptions.