Найти в Дзене
Аналитическая среда

Нотации именования объектов

Что может быть важнее для аналитика, чем общаться с разработчиками на одном языке, по крайней мере в именовании объектов (переменных, классов, функций и других сущностей)? Наверное и есть, но уже понимание того, как называть объекты при их проектировании, чтобы после разработчик их не переименовывал, точно облегчит жизнь и сделает работу более продуктивной. Давайте разберемся в том, какие преимущества использования единой нотации в команде? Рассмотрим основные нотации склеивания названий в именах сущностей на примере названия "System Analyst Best Job": 1. "Camel case (LowerCamelCase)" (верблюжья нотация) - первое слово пишется со строчной буквы, следующие - с заглавной, разделителей между составными частями нет: systemAnalystBestJob Преимущества: 2. "Camel case (UpperCamelCase)" (еще называется Pascal case, нотация Паскаля) - разновидность Camel case нотации с разницей в том, что первая буква тоже заглавная: SystemAnalystBestJob. Как следует из названия - пришел из языка Pascal, где т

Терминология в статье:

  • Нотация - это способ записи имён элементов кода (переменных, функций, классов и других).
  • 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