​​Чистим код: советы по именованию

Записываем в блокнотик:

— Все сущности должны иметь понятные и удобнопроизносимые имена (т.е. никаких a1, a2, a3, temp, foo). Не бойтесь потратить на придумывание названия переменной более 5 секунд. В будущем вы от этого только выиграете.

— Длина названия должна быть пропорциональна области видимости сущности. Вот почему итераторы в маленьких циклах можно называть i, j, k, а какие-то глобальные константы лучше по типу MAX_REQUEST_COUNT.

— Имена классов должны представлять собой существительные или их комбинации.

— Методы в своём названии должны содержать глагол, описывающий действие метода. Если глагол не подобрать — задумайтесь, точно ли эта сущность должна быть методом?

— Стоит избегать названий со словами And, With, т.к. они нарушают принцип единой ответственности (хотя бывают и исключения).

— Если есть группа переменных с общим префиксом, то его ставим в конце, а различные части — вначале: StartButton, StopButton, а не ButtonStart, ButtonStop. Так проще находить нужное в группе нескольких переменных.

#чистимкод

​​Чистим код: Функции

В прошлом посте разбирали основные принципы по именованию программных сущностей. А сегодня разберём как лучше писать функции, чтобы их можно было легко читать и понимать:

— Функция должна быть короткой (хотя есть и исключения). Сложно сказать о норме, но ориентироваться можно на значение не более 10-20 строк.

— Функция должна выполнять чётко одну операцию.

— Правило понижения: код должен читаться сверху вниз. Если в функции А вызывается функция Б, то Б должна следовать после А.

— Функция должна иметь как можно меньше аргументов, т. к. каждый аргумент — это контекст, про который должен знать разработчик. Если аргументов много и они связаны — следует упаковать аргументы в один объект.

— У функции не должно быть побочных эффектов — скрытых действий, о которых разработчик может не догадываться.

— Касательно комментариев к функциям от Роберта Мартина: "Комментарии должны компенсировать неудачу в выражении мыслей в коде. Комментарии — признак неудачи". Чистое именование функции и её реализация избавляет разработчика от необходимости написания для неё комментария. Конечно, есть и исключения: авторские права, TODO-листы, объяснения важности или предупреждения.

#чистимкод

Паттерны и практики написания кода

Разработчики уже давно отошли от подхода, при котором от кода требовалась лишь работоспособность. Сейчас принято писать «чистый» и читабельный код, чтобы остальным разработчикам и вам самим было возможно в нём разобраться. Что именно нужно делать с кодом — рассказывают в этом курсе. Тут разбирают три основных вопроса:

— как улучшить качество кода;
— как работать с исключениями;
— полезные архитектуры и шаблоны проектирования.

Смотрим тут

@prog_point #советы #чистимкод #general