Привет!
Сегодня неожиданно захотелось поговорить про стили наименования переменных и констант с точки зрения системного аналитика и связанного с этим забавного (для меня) случая из практики.

Для начала объясню, что это вообще такое. В программировании есть такой понятие как "Стиль написания составных слов" и их достаточно не много на выбор. Всё это служит для того, чтобы прийти всем миром к определенным стилистическим правилам оформления кода для лучшей читаемости любым человеком.

Например, нам нужно каким-то образом обозначить параметр, в котором должно хранится значение, допустим, номера договора по кредиту. Как назвать эту переменную? documennumber? DocumentNumber? DOCUMENTNUMBER?
Вариантов на самом деле достаточно много. И чтобы обеспечить единообразие наименования всех классов и переменных разработали стили, про которые упомянул выше.

Вот они:
lowerCamelCase = documentNumber.
CamelCase (PascalCase) = DocumentNumber
snake_case = document_number
SCREAMING_SNAKE_CASE = DOCUMENT_NUMBER
kebab-case = document-number

Это основные стили, которые я встречал на практике.

Изначально инициатива по выбору стиля написания для наименования не исходит от СА, а от разработчиков. СА в свою очередь просто поддерживает эту стилистику в своих ТЗ, т.к. именно нам приходится прорабатывать модель данных, наименования всех параметров для API, для БД и в прочих местах, поэтому для нас это тоже важно, выдерживать единый стиль.

Где это применять:
1. lowerCamelCase - для наименования параметров, переменных;
2. CamelCase - наименование объектов (например в API);
3. SCREAMING_SNAKE_CASE - наименование столбцов таблиц в БД.

Теперь случай из практики.
Вообще я принадлежу миру Java и рад этому. И за 6 лет работы СА в этом мире я очень привык к тому, что все сущности называются по 3 правилам, которые я привел выше. И тут выдалось мне поработать с командой разработки, которая писала на питоне, фреймворке Jango.
Я, конечно же, по привычке накидал описание кучи апишек и еще большей кучи различных моделей данных согласно этим стилям. Спустя несколько недель команда разработки дошла до согласования этих ТЗ и была очень удивлена и даже негодовала на тему того, что я использовал именно эти стили, потому что на питоне и их фреймворке было принято именовать переменные в snake_case. И мне пришлось переименовывать вообще всё что я написал так, как им удобно (тут не было выхода, потому что документация всегда должна совпадать с реализацией, это самое главное требования и его нельзя (и не нужно) обходить). Но не могу не сказать, что я делал это буквально через силу и действительно не мог заставить себя именовать переменный таким образом, очень уж за столько лет привычка въелась строго определенная.

Это не говоря о своеобразных вещах, например того, что для некоторых параметров вроде "Даты создания" были забронированы строго определенное наименование created_at (мой вариант был created_time) и по-другому назвать было нельзя)
Но тут в чужой монастырь со своим уставом не лезут, поэтому сделал так, как требовалось, как бы руки не сопротивлялись.

P.S. Если у кого-то на практике возникали похожие ситуации - пишите в комментариях, обсудим)