Терминология в статье:
- Нотация - это способ записи имён элементов кода (переменных, функций, классов и других).
- SDLC - Software Development Life Cycle - жизненный цикл разработки программного обеспечения.
- Best practises (лучшие практики) - набор принципов и действий, которые признаны наиболее эффективными в определённой области.
Что может быть важнее для аналитика, чем общаться с разработчиками на одном языке, по крайней мере в именовании объектов (переменных, классов, функций и других сущностей)? Наверное и есть, но уже понимание того, как называть объекты при их проектировании, чтобы после разработчик их не переименовывал, точно облегчит жизнь и сделает работу более продуктивной.
Давайте разберемся в том, какие преимущества использования единой нотации в команде?
- код становится более структурированным и единообразным, что облегчает прочтение и понимание другим участниками команды (разработчиками, аналитиками, тестировщиками);
- согласованность кода, упрощающая адаптацию или погружение новых сотрудников в проект;
- экономия времени при именовании объектов (не нужно задумываться над тем, как "правильно" именовать в каждом определенном случае);
- участники команды разговаривают на одном языке в части именования объектов на протяжении всего жизненного цикла разработки ПО (SDLC) от момента сбора требований до сдачи продукта в эксплуатацию.
Рассмотрим основные нотации склеивания названий в именах сущностей на примере названия "System Analyst Best Job":
1. "Camel case (LowerCamelCase)" (верблюжья нотация) - первое слово пишется со строчной буквы, следующие - с заглавной, разделителей между составными частями нет: systemAnalystBestJob
Преимущества:
- удобство чтения за счет наличия разделителей смысловых частей в виде заглавных букв;
- нет необходимости вводить в названия дополнительные символы, которые могут не поддерживаться отдельными языками программирования
- широкое использование и поддержка в различных языках программирования (имена переменных и функций)
2. "Camel case (UpperCamelCase)" (еще называется Pascal case, нотация Паскаля) - разновидность Camel case нотации с разницей в том, что первая буква тоже заглавная: SystemAnalystBestJob.
Как следует из названия - пришел из языка Pascal, где так было принято именовать объекты. Преимущества те же, что и у LowerCamelCase с поправкой на то, что в первую очередь в некоторых языках (JS, Python, Java) используется для именования классов.
3. "Snake case" (змеиная нотация) - слова разделяются (или объединяются, кому как удобнее считать) символом подчеркивания, используют преимущественно строчные буквы: system_analyst_best_job.
Из преимуществ можно отметить:
- универсальность - можно использовать для именования любых объектов (переменных, функций, классов и других);
- минимум ошибок при написании за счет простоты написания - не нужно запоминать и переключать раскладки при вводе имен.
Нужно заметить, что данная нотация не такая популярная как Camel case, что может усложнить переход на неё из других нотаций + не всегда принято использовать в некоторых языках программирования.
Чаще всего применяется в языках Perl, Python, PHP, Ruby, Rust и других.
4. "Screaming snake case" (кричащая змея) - тоже, что Snake case, но все буквы заглавные: SYSTEM_ANALYST_BEST_JOB.
Преимущества:
- повышенная читаемость кода - слова в коде, написанные заглавными буквами, более четко разделяет код на смысловые конструкции;
- подчеркнутая неизменяемость - в некоторых языках используется для обозначения констант и написание заглавными буквами подчеркивает их неизменность.
В Python, PHP, Rust используется для обозначения системных констант.
5. "Kebab case" (шашлычная нотация) - слова записываются в нижнем регистре и разделяются символом дефис: system-analyst-best-job.
Преимущества:
- совместимость с веб-стандартами - подходит для использования в URL-адресах, именах классов CSS и идентификаторах HTML, где использование других символов могут вызвать проблемы;
Интересная нотация, применяемая в основном в web-проектах (URL, CSS, HTML). Область применения ограничена тем, что во многих языках символ дефис интерпретируется как операция минус (вычитание)
6. "Cobol case" (COBOL нотация) - тоже, что Kebab case, но все слова пишутся заглавными буквами: SYSTEM-ANALYST-BEST-JOB.
По мнению авторов языка COBOL имеет преимущество в виде читаемости и близости к английскому языку, когда каждое из слов в имени имеет смысловую нагрузку и вместе представляют законченную фразу: "execute until a condition" -> "EXECUTE-UNTIL-CONDITION".
В настоящее время применяется в основном в программах на одноименном языке COBOL.
7. "Flat case" (плоская нотация) - все слова пишутся строчными буквами слитно без разделителей: systemanalystbestjob.
Преимущество данной нотации в простоте написания, особенно если не удается придумать название объекта одним простым словом.
Странно, непонятно, сложно читать, особенно если название включает в себя несколько слов.
8. "Венгерская нотация" - имена объектов (чаще переменные и константы) предваряются заранее оговорёнными префиксами из одного или нескольких символов: sAnalyst (переменная типа строка).
Префиксы, чаще всего, обозначают тип данных и класс объекта, но возможны и иные использования. Данная нотация несколько выделяется из общей массы нотаций, перечисленных выше, ибо предназначена для обозначения назначения или типа объекта, но не того. по каким правилам "склеивать" сложные названия.
Преимущества:
- возможность указывать не только тип, но и подтип объекта, за счет использования составных префиксов;
- при использовании стандартных префиксов у пользователей потенциально упрощается работа с объектами в части понимания типа и назначения объекта;
Использование венгерской нотации имеет и свою нюансы, в частности:
- имена переменных делаются менее понятными для восприятия;
- изменение типа переменной приводит к необходимости её переименования;
И конечно есть все возможные комбинации выше перечисленных нотаций 🙂
При таком разнообразии вариантов именования объектов возникает вопрос: "Существуют ли best practises в именовании объектов в разработке?"
Безусловно, в программировании за свою историю накопился ряд рекомендаций для именования и большинство из них основывается на цели именования.
"Цель именования - чётко передать назначение и содержание объекта, таким образом сосредоточив внимание не на именах объектов, а на их использовании в процессе разработки программы".
Рекомендации следующие:
- используйте имена, не требующие пояснений и точно отражающие хранимые в них данные;
- выбирайте такие имена, которые точно отражают назначение объекта, но не создают избыточной сложности;
- избегайте сокращений, лишающих имена смысла. Прозрачные и понятные слова играют ключевую роль в создании качественного кода;
- обеспечьте единообразие именования в пределах проекта или команды. Установите единые правила выбора имен и следуйте им, чтобы минимизировать возможность появления ошибок и сделать код легко поддерживаемым всеми разработчиками.
Выбор нотации зависит от ряда факторов:
- Язык программирования: каждый язык программирования имеет определенные ограничения в именовании объектов, а также собственный набор рекомендаций по именам;
- Стандарты оформления кода: в каждой компании (особенно крупной) есть собственный внутренний стандарт оформления кода, основанный на внутренних лучших практиках;
- Поддержка существующей кодовой базы: если проект реализуется на базе уже внедренного решения, то есть необходимость соблюдать раннее установленные правила, чтобы обеспечить единообразие во всей кодовой базе проекта;
- Внутренние договоренности команды: команда раннее договорилась об единых правилах именований и следует им;
- Привычки и предпочтения: каждый разработчик (и команда в целом) имеют свой устоявшийся набор привычек, который нужно учитывать при выборе правил именования;
Самое главное - это предварительно договориться со всеми участниками о едином подходе и следовать ему!
Как сказал Фредерик Брукс "Серебряной пули не существует" (те единого универсального решения на все случаи жизни не существует)
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse