Сейчас я читаю во второй раз замечательную книгу Чистый код Роберта С. Мартина, также известного как дядя Боб, и я думаю, что это хорошая идея записать наиболее важные идеи, которые он пытается донести до нас. Сегодня я сосредоточусь на второй главе.
Имена классов
Классы и объекты должны иметь существительные или именные словосочетания, такие как Customer, WikiPage, Account или AddressParser. Избегайте таких слов, как Менеджер, Процессор, Данные или Информация в названии класса. Имя класса не должно быть глаголом.
Имена методов
Методы должны иметь названия глаголов или словосочетаний, например postPayment, deletePage или save. Аксессоры, мутаторы и предикаты должны называться по их значению и иметь префиксы get, set и is в соответствии со стандартом JavaBean.
Когда конструкторы перегружены, используйте статические фабричные методы с именами, описывающими аргументы. Например:
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
обычно лучше, чем
Complex fulcrumPoint = new Complex(23.0);
Рассмотрите возможность принудительного их использования, сделав соответствующие конструкторы закрытыми.
Выберите одно слово для каждой концепции
Выберите одно слово для одного абстрактного понятия и придерживайтесь его. Например, использование методов fetch, retrieve и get в качестве эквивалентных методов разных классов может привести к путанице. ¿Как запомнить, какое имя метода относится к какому классу?
Имена функций должны быть автономными, и они должны быть согласованными, чтобы вы могли выбрать правильный метод без каких-либо дополнительных исследований.
Точно так же наличие контроллера, менеджера и драйвера в одной и той же кодовой базе сбивает с толку. ¿В чем существенная разница между DeviceManager и ProtocolController? ¿Почему оба не контролеры или оба не менеджеры?¿ Действительно ли они оба Водители? Название наводит вас на мысль о двух объектах, которые имеют очень разные типы, а также разные классы.
Не каламбур
Избегайте использования одного и того же слова в двух целях. Использование одного и того же термина для двух разных идей.
Если вы будете следовать правилу «одно слово на понятие», вы можете получить множество классов, которые имеют, например, метод add . Пока списки параметров и возвращаемые значения различных методов добавления семантически эквивалентны, все в порядке.
Однако кто-то может решить использовать слово добавить для обозначения «постоянства», когда он или она на самом деле не добавляет в том же смысле. Допустим, у нас есть много классов, в которых add создаст новое значение путем добавления или объединения двух существующих значений. Теперь предположим, что мы пишем новый класс, у которого есть метод, который помещает свой единственный параметр в коллекцию. ¿Должны ли мы называть этот метод add? это может показаться последовательным, потому что у нас так много других методов add , но в этом случае семантика отличается, поэтому мы должны использовать имя, подобное insert или добавитьвместо этого. Вызвать новый метод add было бы каламбуром.
Используйте доменные имена решений
Помните, что люди, которые читают ваш код, будут программистами. Так что вперед, используйте термины компьютерных наук, имена алгоритмов, имена шаблонов, математические термины и так далее.
Название AccountVisitor много значит для программиста, знакомого с шаблоном VISITOR. ¿Какой программист не знает, что такое JobQueue? Есть много очень технических вещей, которые должны делать программисты. Выбор технических имен для этих вещей обычно является наиболее подходящим курсом.
Выводы
Самое сложное в выборе хороших имен заключается в том, что это требует хороших описательных навыков и общего культурного опыта. Это проблема обучения, а не техническая, деловая или управленческая проблема. В результате многие люди в этой области не учатся делать это очень хорошо. Постарайтесь не быть частью этих людей.
