1. Использование имен, раскрывающих намерение
Имя переменной, функции или класса должно отвечать на все большие вопросы. Он должен рассказать вам, почему он существует, для чего он нужен и как он используется. Если имя требует комментария, то имя не раскрывает его намерения.
2. Избегайте дезинформации
Программисты не должны оставлять ложных ключей, которые затемняют смысл кода. Мы должны избегать слов, значение которых отличается от предполагаемого значения.
например hp, aix и sco - плохие имена переменных.
Подобное написание аналогичных понятий - это информация. Использование непоследовательного написания является дезинформацией.
3. Делайте значимые различия
Недостаточно добавить числовой ряд или шумовые слова, даже если компилятор удовлетворен. Если имена должны быть разными, они также должны означать что-то другое.
Делайте значимые различия
Именование числовой серии {a1,a2,...aN} является противоположностью намеренного присвоения имен. Такие имена не дезинформативны - они неинформативны; они не дают ключа к разгадке намерений автора.
Шумные слова - еще одно бессмысленное различие. Шумовые слова излишни. Например. Имея класс Product, также есть другой, называемый ProductInfo или ProductData.
Различайте имена так, чтобы читатель знал, в чем заключаются различия.
4. Используйте произносимые имена.
Например. genymdhms должно быть GenerationTimestamp.
5. Используйте имена с возможностью поиска
Однобуквенные имена и числовые константы имеют особую проблему, поскольку их нелегко найти в тексте.
Лично я предпочитаю, чтобы однобуквенные имена можно было использовать ТОЛЬКО как локальные переменные внутри коротких методов. Длина имени должна соответствовать размеру его области.
6. Избегайте кодировок.
Кодирование информации о типе или объеме в имена просто добавляет дополнительную нагрузку на расшифровку.
1. Венгерская нотация
Это только в старые времена, когда компилятор не проверял типы.
2. Префиксы участников
Вам больше не нужно ставить перед переменной-членом префикс m_.
3. Интерфейсы и реализации
Например. IShapeFactory и ShapeFactory
7. Избегайте ментального картирования.
Это проблема с однобуквенными именами переменных.
Одно из различий между умным программистом и профессиональным программистом состоит в том, что профессионал понимает, что ясность - главное.
8. Имена классов
Классы и объекты должны иметь имена существительные или именные словосочетания. Избегайте таких слов, как Manager, Processor, Data или Info в названии класса.
9. Имена методов
Методы должны иметь глагольные названия или глагольные фразы, такие как postPayment, deletePage или save. Аксессоры, мутаторы и предикаты должны быть названы в соответствии с их значением и иметь префикс get, set и is в соответствии со стандартом javabean.
Когда конструкторы перегружены, используйте статические фабричные методы с именами, описывающими аргументы.
Например. Complex fulcrumPoint = Complex.FromRealNumber(23.0); лучше, чем Complex fuldrumPoint = new Complex(23.0);
Рассмотрите возможность принудительного их использования, сделав соответствующие конструкторы закрытыми.
10. Не будь милым
Скажите, что вы имеете в виду, имеете в виду то, что вы говорите.
Например. whack() и kill(), eatMyShorts() и abort().
11. Выберите одно слово для каждой концепции.
Выберите одно слово для одного абстрактного понятия и придерживайтесь его. Сбивает с толку, когда fetch, retrieve и get являются эквивалентными методами разных классов.
Сбивать с толку контроллер, менеджер и драйвер в одной и той же кодовой базе. В чем разница между ними?
Последовательный лексикон - большое благо для программистов, которым приходится использовать ваш код.
12. Не качайте
Избегайте использования одного и того же слова в двух целях.
Наша цель как авторов - сделать наш код максимально простым для понимания.
13. Используйте доменные имена решения
Помните, что люди, которые читают ваш код, будут программистами. Так что продолжайте и используйте термины CS, имена алгоритмов, имена шаблонов, математические термины и так далее.
14. Используйте имена проблемных доменов
Разделение концепций решения и проблемной области - часть работы хорошего программиста и дизайнера.
15. Добавьте значимый контекст
Вам нужно поместить имена в контекст для вашего читателя, заключив их в хорошо названные классы, функции или пространства имен. Когда ничего не помогает, в крайнем случае может потребоваться добавление префикса к имени.
16. Не добавляйте беспричинный контекст
Короткие имена, как правило, лучше, чем длинные, если они ясны. Добавляйте к имени не больше контекста, чем необходимо.
