Известная фраза в SWE, сказанная инженером из Netscape более 20 лет назад. “There are only two hard things in Computer Science: cache invalidation and naming things” :)

Так, что проблема, мягко скажем, не нова. Подход в статье по ссылке ниже, на мой взгляд, неоправданно механистичный и недостаточно результативный.

Для разработки есть более надежные. Самый важный инструмент для результативного нейминга идентификаторов в коде был описан в книге Эрика Эванса DDD в 2003 году. Он называется Ubiquitous Language. Это фактически и есть база для нейминга - термины предметной области, которые инженер стандартизуетт в уникальный словарь.

По таким именам сразу становится предметно понятна предметная функциональная нагруза переменной, поля, метода, класса. Напр. объект `UploadedFileStreamValidation`. Фактически, читатель кода сразу читает на языке предметной области.

Прочитав такое название мы сразу понимаем обязанности объекта.

Теперь надо понять положение объекта в формальной иерархии обязанностей, универсальной для для очень многих предметных областей. Тут DDD снова приходит на помощь. Он уже определил архетипы объектов, которые четко ограничивают их формальныей обязанности. И таких архетипов всего-ничего - 7 наиболее полезных. Value Object, Entity, Aggregate, Domain Service, Application Serviсe, Repository, Factory и еще несколько.

Добавляем такой архетип к нашему идентификатору и получаем `UploadedFileStreamValidationService`. Теперь понятно место этого объекта в системе, его обязанности и отношения с другими объектами. Собственно, это база.

Теперь немного простых конвенций.

- Интерфейсы всегда начинаются на I. - Типы начинаются на T. - Перечисления (enums) начинаются с буквы E. - Аббревиатуры всегда пишутся заглавными буквами. - Имена классов всегда в стиле PascalCase. - Имена переменных и параметров — в стиле camelCase. - Свойства объектов и поля базы данных — в стиле snake_case. - Константы — в стиле ALL_CAPS_SNAKE_CASE.

Всегда можно добавить собственные конвенций, если они кажутся полезными.

Код, в котором такой подход применяется последовательно, становится намного читаемее и понятнее (!).

С помощью такого подхода к неймингу можно создавать очень крупные системы.

На мысль натолкнул вот этот пост Максима Белугина https://set.ki/post/5mk3dez.

Спасибо ему.

Буду рад обсудить, если кому интересно.