Комментарии 27
Жесть.
У меня смутное ощущение, что с текстом что-то не так:
Именование несёт, грубо говоря, три функции:
Пока пишешь код - нужно создавать имена переменных. При наличии системы не нужно вспоминать какие переменные нужно использовать. Легче их сконструировать. При стандарте именования каждый раз должно получаться одинаковое имя. В вашей статье этого нет.
Пока читаешь свой код - нужно восстанавливать характер переменных. При наличии системы не нужно вспоминать характер переменных, когда он на экране. А сведение несовместимого, сложение яблок и апельсинов, должно кричать с экрана про неестественность. В статье это раскрыто не полно.
Пока читаешь чужой или давний код - нужно восставливать характер задачи. При наличии системы именования, несмотря на долготу чтения, задачу можно читать, как бы на родном языке. В статье это перечёркнуто.
Разумеется, нельзя писать имена подробными фразами грамматиками естественного языка. Это просто затмит операции, так как они односимвольные. (Хотя для смеху можно их макросами препроцессора тоже заменить глаголами естественного языка).
Но весь ваш текст, как будто, борется только с этой одной мыслью.
Про REST контроллеры абсолютно согласен, там использование get вполне уместно и действительно добавляет в код полезный смысл. Вот например пример кода
import io.javalin.Javalin;
public class HelloWorld {
public static void main(String[] args) {
Javalin app = Javalin.create().start(7000);
app.get("/", ctx -> ctx.result("Hello World"));
}
}get именно в этом косучке кода выглядит полезным и нужным, потому что он идет из предметной области в которой работает этот код, обработка HTTP запроса.
И это кстати ещё раз подтверждает что нет единой системы наименования в которую можно уложить все названия, вот в REST контроллерах get нужен и полезен.
Название getOrCreateFolder() слишком переусложенено ненужными деталями. Опятьже, функци должна называться так, что она возвращает. Более хорошее название для этой функции folder(), оно нисколько не снижает понимание кода
folder().remove(file)по сраунению с
getOrCreateFolder().remove(file)но в то же врем легче читается
Опятьже, функци должна называться так, что она возвращает
У меня есть функция FolderId, есть идеи, что она делает? Подсказка: она принимает путь к каталогу
И ещё есть функция, ничего не возвращающая, как её назвать?
Более хорошее название для этой функции folder(), оно нисколько не снижает понимание кода
Вы серьёзно не видите разницу между folder и getOrCreateFolder?
У меня есть функция FolderId, есть идеи, что она делает?
Возвращает какой-то номер из ОС, относящийся в папке. inode, например
И ещё есть функция, ничего не возвращающая, как её назвать?
функция, ничего не возвращающая, должна называться глаголом, add, remove, rename, modify, fetch, update, push, send, receive, connect, write… Все эти функции что-то делают, но не должны ничего возвращать
getOrCreateFolder() - это вообще не хорошо. Нарушен Принцип единственной ответственности
Вы путаете предмет обсуждения. При этом опираясь на умозрительные примеры названий.
Фасад тут не при чём. И с точки зрения нейминга подобное название Фасада то же плохое. Фасад прячет сложность, оставляя наружу только нужное.
Моё замечание касалось имени. Имя предполагает два действия и логический оператор. Что делает функция в данном конкретном месте нельзя понять не изучив её код.
Идея предложенной здесь https://habr.com/ru/post/558874/ методики (как и многих других) в том чтоб сделать код понятным для чтения.
getFolder - вообще ни когда не понятно что тут происходит. Получаем путь к папке? Получаем доступ к папке? Получаем содержимое папки? Имя папки?....
Про get вообще мимо. Глагол обязателен в массе конвенций.
В rust не используется приставка «get_» для геттеров, как мне теперь жить-то?
Совершенно спокойно, get- и set- это Java-догма
Во-первых используется. Как исключение, но используется. И встречается в проектах не редко.
Во-вторых читать оригинальную статью не которую в начале текста ссылается автор. Там упоминается о том что в языках бывает своя специфика (правда вскользь)
В-третьих не стесняться думать. В оригинальной статьей предложена методика. Она не догма и, конечно, может и должна корректироваться
const isBlue = (color === 'blue');
const hasProducts = (productsCount > 0);А в реальном коде у меня условия гораздо длиннее, например
const isVipClientOrder = (orderType == 932874) || (orderType == 90823475) || (orderType == 1893958) || (orderType == 29457171);И что, по замыслу автора, нужно копипастить эту конструкцию каждый раз, когда она потребуется?
Нет, конечно же. Ещё раз повторюсь, нет единой системы по которой придумываются и используются названия. В случае длинного выражения действительно имеет смысл использовать переменную. Но вполне достаточно её назвать isVip или даже просто vip, вполне понятно будет, нисколько не менее понятно чем длинное название isVipClientOrder.
В языке по типу Котлин можно было бы описать метод в контексте его надобности (глобально описать трудно, т.к Vip в разном контексте может быть разный, тогда и методов будет куча) и сделать так
order.isVip()И не надо никаких переменных. Но увы не все языки так могут. Вот и получаем кучу переменных с подробностями что бы не путаться
Во всех мне известных нотациях fruits — это коллекция/перечисление того или иного вида. И я совершенно точно хочу понять смысл функции по её названию, если это вообще возможно (бывают случаи, когда без документации никуда). Для примера, с fruits мне придётся как минимум посмотреть на возвращаемый тип, и это точно зря потратит моё время.
Примерно такая же ошибка в большинстве приведённых советов.
Отдельно про контекст и память. Тут аргументация вообще ясельная. Вот скажите, вы когда книги или статьи читаете, может уловить смысл фразы длиннее 7 слов? А смысле текста длиннее 7 фраз? Я думаю, что вы с этим справляетесь вполне успешно. Название переменной — это вообще всего лишь слово в тексте программы. Да, составное, да, возможно новое, что требует чуть больше внимания при прочтении, но сложность равно такая, как при чтении составных слов — главное чтобы структура слова была корректна, все корни известны и чтобы оно передавало правильный смысл.
Так что этой проблемы нет. А вот разгадывать, что именно значит то или иное название в той парадигме, которую вы предлагает, совсем не хочется.
Использование имени функции без глагола сродни анекдоту:
Борт номер 1234, приборы!
200
Что 200?
А что приборы?
Имя свойства можно и без глагола, а имя метода - очень желательно!
class ApiPosts
{
var posts
void fetch(count) { posts = fetch('https://api.dev/posts', {...}); }
}
Вот это прям лютый антипаттерн - на ровном месте создать зависимость между членами класса, похоронить потокобезопасность, сделать вызовы более многословными (прощай expression body), и все это ради... А ради чего, собственно? Плюсов я не вижу.
Зря автор не стал писать комментарий к оригинальной статье. Интересное обсуждение развалилось на два. Ну да ладно.
Код пишется для человека. В этом у нас нет расхождений. Совсем будет хорошо, если ваш код поймёт человек имеющий только общее представление о его назначении.
А вот дальше у вас написано совсем не про чистый совершенный код:
Поэтому, пока он читает слова should, display, pagination, у него из памяти вытесняются другие объекты, возможно детали алгоритма, которые он пытается понять, читая исходный код. В итоге, человек хуже поймет алгоритм, и сделает ошибку при его исправлении или использовании. Слишком описательные названия, как ни странно, ведут к прямо противоположному результату, к ухудшению понимания и большему количеству ошибок.
Если ваш код так написан, что пока его читаешь забываешь о чём прочитал, то вам точно надо его переписать. Упростить, разбить на понятные блоки/модули/функции/классы и т.п.
Любая система именования...
...ухудшает читаемость и поддерживаемость кода
Гм... В Microsoft, Google, Apple и т.д. дураки сидят и от нечего делать naming conventions используют (легко гуглится). Соглашения об наименовании для того и принимаются чтоб облегчить дальнейшую поддержку кода.
Правила наименования прекрасно вписываются в табличку. Надо просто подобрать/придумать табличку для конкретного случая. Адаптировать чьи-то рекомендации всегда проще чем придумывать с нуля.
Дальше автор зачем-то начинает пытаться разрушить предложенную методику, не предлагая при этом ни какой. Точнее предлагая писать "как хочется"
Смысл статьи в первую очередь был в том чтоб показать читателям один из подходов и объяснить его.
Тем более глупо пытаться "улучшить" модельные примеры. И упущен важный момент! Мы программируем на английском языке!!! Пытаться поправить названия через прямой, а затем обратный, переводы - это вообще не уместно.
Ещё один важный плюс от применения соглашения об именовании: люди из разных стран, языков, культур - одинаково поймут написанный код. (Например английский заметно отличается у англичан и американцев, немецкий у германских и австрийских немцев тоже. Речь не о произношении а о правилах языка)
Резюме:
Наименования переменных, функций и классов это сложно. Сложно подобрать понятные, очевидные и подчеркивающие предметную область названия.
Но совершенно точно эти названия надо уложить в стройную систему. Для улучшение читаемости кода и качества его поддержки.
Именуйте классы, переменные и функции для людей, а не для машин