Для меня поиск хорошего имени для чего-то всегда возвращается к мысли о нем как об объекте, который должен оправдывать его существование. Спроси себя:
- Что делает класс / метод / переменная, то есть какова его более широкая цель и для чего она нужна?
- Что конкретно о его цели нужно сообщать, то есть, что является важной частью, что имя должно иметь в нем?
Большинство разработчиков согласны с тем, что удобочитаемость всегда имеет первостепенное значение, когда дело доходит до именования. Не просто пишите код, чтобы вы знали, что вы имеете в виду во время написания, пишите так, чтобы кто-то, кто смотрит на код впервые в будущем, знал, что вы имели в виду, не думая слишком много. Вы напишете код только один раз, но в течение его жизни его, скорее всего, придется редактировать много раз и читать еще больше.
Код должен быть самодокументированнымто есть, ваше наименование должно показывать, что что-то делает. Если вам нужно объяснить, что строка кода делает в комментарии, и переименование вещей недостаточно улучшает ее, вам следует серьезно подумать о рефакторинге этой строки в новый метод с соответствующим описательным именем, чтобы чтение исходного метода, вызов нового метода описывает, что происходит. Не бойтесь иметь длинные имена; Конечно, вы не должны писать романы в именах классов / методов / переменных, но я бы предпочел, чтобы имя было слишком длинным и описательным, чем слишком коротким, и мне нужно выяснить, что оно делает, заглянув под капот. За исключением некоторых очевидных исключений, таких как координаты x / y и часто используемые аббревиатуры, избегайте односимвольных имен и сокращений. Вызов чего-то "bkBtn" вместо "backButton"
Столько, сколько позволяет ваш язык, сделайте так, чтобы ваш код читался как английское предложение. Объекты используют существительные, методы используют глаголы. Булевы методы обычно начинаются с «is», но есть много других опций, которые передают значение еще лучше, в зависимости от варианта использования, таких как «can», «should» или «делает». Конечно, не все языки могут быть настолько хороши, как Smalltalk, но некоторые символы обычно считаются частями предложения. Два соглашения Smalltalk, которые я лично хотел бы перенести на другие языки в максимально возможной степени, - это добавление префикса имени цикла к параметру «each» и добавление параметра метода к статье «a» (или «an», или «some» для коллекций). , Это может не быть распространенным стандартом в Java, и любой может проигнорировать этот бит, но я считаю, что это значительно улучшает читабельность кода. Например (пример на Java):
public boolean shouldConsiderAbbreviating(List<String> someNames) {
for (String eachName : someNames) {
if (isTooLong(eachName)) {
return true;
}
}
return false;
}
Это должно быть доступно для чтения людям с небольшим знанием Java как-то так:
Чтобы определить, стоит ли сокращать список некоторых имен (которые являются строками), перебирайте некоторые имена и для каждого имени определяйте, является ли он слишком длинным; если так, вернись true; если ни один не слишком длинный, вернитесь false.
Сравните приведенный выше код с простым именованием аргумента stringsи переменной цикла string, особенно в более сложном методе. Вы должны внимательно посмотреть, чтобы увидеть разницу, а не использование очевидным с первого взгляда на название.