Привет, сегодня речь пойдёт о правильном выражении своих мыслей при написании кода в части именования различных сущностей вашей программы.
О наболевшем
Почему я решил об этом написать? Тихий ужас твориться во многих программах, которые я вижу, потому что основная проблема русскоязычных программистов, это косноязычность. Мы не очень хорошо знаем английский, чтоб подбирать хорошие точные слова на нём, поэтому мы очень любим использовать Stop, Start, Publish, вообщем всякие названия, которые очень примитивны, и которые используются во всех возможных контекстах и иногда очень сильно запутывают всех членов команды.
Общие советы
Начнём с того, что всегда советуется абсолютно везде.
Вот пять основных советов по именованию переменных:
- Старайтесь максимально точно выразить смысл переменной, класса метода и т.д.
- Для имён классов, переменных, констант - использовать существительные. Для имен функций и методов - глаголы.
- Используйте ключевые слова, подходящие по смыслу к типу переменной
- Не используйте малопонятные аббревиатуры
- Чем больше область видимости переменной, тем более длинное имя ей можно дать
После того как мы определились с общими правилами, дальше нужно определиться каким образом выделать многословные конструкции в именах переменных и функций. Вот четыре общепринятых стиля написания:
- camelCase
- snake_case
- kebab-case
- PascalCase
В первом случае первое слово многословной конструкции начинается с маленькой буквы а все остальные с большой. Во втором слова пишутся через подчёркивание, в kebab-case через дефис, а
в PascalCase все слова начинаются с заглавной буквы. Обычно всё это используется вперемешку, например в наименование файлов может использоваться snake_case или Kebab-case. для именования классов PascalCase, для именования переменных camelCase. Это зависит от ваших личных предпочтений и предпочтений ваших коллег.
Поговорим о нюансах
Хочу сказать о именовании и использовании аббревиатур, на мой взгляд это очень спорный пункт, который все любят цитировать и очень тупо ему следуют. Если у нас в проекте будет очень много описательных переменных многословных, то это превращается при разработке в какой-то ад. Вспомните, например досовскую аннотацию, 8 символов под имя файла 3 под расширения, и хватала этого более чем достаточно. Потому что всегда можно найти очень много способов выразить свою мысль в таком формате, 8 на 3. Поэтому я считаю, что имя переменных тоже не должно превышать 11 -12 символов, кончено есть исключения, чем чаще используется переменная, тем больше смысл сделать его коротким. Я очень большой сторонник аббревиатур, потому что есть очень много бизнес специфичных аббревиатур, какую бы вы область не взяли, вы всегда столкнётесь с устоявшимися для бизнеса аббревиатурами, которые очень полезно использовать в коде. Любые разработчики, которые идут на проект первые 2-3 месяца будут испытывать проблемы с этими аббревиатурами, но потом привыкнут, и начнут мыслить именно этими категориями. Второй момент, многие аббревиатуры, являются устоявшимися, RGB заменять на redGreenBlue будит наверно только очень, очень упёртый человек.
Про косноязычность
Как я уже обозначил в начале, наша основная проблема — это косноязычность, слишком уже мы мало в повседневной жизни на английском языке. Я уверен, что кто-то и много общается, но даже хорошо общаясь с людьми на английском языке, даже находясь в англоязычной стране, это не гарантирует ого, что вы избавитесь от своей косноязычности. Потому, что вполне возможно, что вы используете 200-400 слов которых вам хватает, а когда вы начинаете, выражать свои мысли в коде оказывается, бытовой речи, очень даже не достаточно, по этому здесь нужно брать словарик, не стесняться использовать словарные слова, если вы подзабыли значения слов то восстановить, и вообще в целом расширять словарный запас это в принципе как у писателей, очень полезно разработчикам иметь хороший богатый словарный запас.
Про приватный мусор
Есть такое мнение, что внутри своего класса вы можете делать любую помойку, устраивать любой беспорядок, главное, чтобы с наружи всё было красиво и понятно, и сосредотачиваться нужно в первую очередь над именованием публичных методов, публичных переменных. Я сторонник другого подхода, скорее всего с вашим кодом, так или иначе будут работать другие люди, поэтому если вы слишком увлекаетесь короткими мало информативными названиями это будет вредить проекту, когда к нему будут подключаться новые люди.
Я до сих пор переживаю за качество названий своих классов, функций, переменных, до сих пор у меня есть внутренние противоречия по этому поводу. Наверное, они на всю жизнь будут со мной, поэтому в этом процессе совершенства нет, каждый день нужно трудиться и двигаться к цели.