I am ready for a long road flight for working with a week- or months-long projects.
Сокращения в именах: благо или вред?
Введение
В программировании часто используют сокращения для именования переменных, методов и классов. Например, cfg вместо configuration или id вместо identifier, что делает код компактнее без потери читабельности.
Хоть данный подход и широко распространен, но следует отметить, что он практикуется не везде. В некоторых компаниях и проектах использование сокращений запрещено или строго регламентировано.
Также часто используются аббревиатуры, но лишь в случае широко распространённых или специфических для конкретного проекта терминов.
- Аббревиатуры
Использование аббревиатур в коде несомненно положительно влияет на его читаемость. Это обусловлено тем, что они настолько укоренились в нашем сознании, что их расшифровка лишь затруднит понимание: URL, HTML, JSON и т. д. В специализированных областях (банковские системы или телекоммуникации) применение аббревиатур является стандартом – например, KYC, QoS, ROI и пр.
Споры относительно использования аббревиатур в среде разработчиков минимальны. Основные разногласия касаются правил записи: следует ли записывать их полностью заглавными буквами или же достаточно делать только первую букву заглавной.
Обратимся к исходникам Java для анализа подхода ведущих разработчиков:
- XMLDocumentHandler
- SSLContext
- HttpClient
- randomUUID()
- XMLReader xmlReader
- HttpURLConnection
- XMLDTDHandler
Мда! Глядя на этот "зоопарк" стилей именования, сложно определить единый подход.
Предлагаю вам простое правило именования, которое никогда не подведет:
Не используйте прописные буквы при наличии аббревиатур в именах переменных. Применяйте CamelCase, если аббревиатура является частью многословного имени.
Пример:
int cpuNumbers
int ram
int shortUrl
class SslConfiguration
class HttpRequestВ пользу только первой заглавной буквы говорят имена вида XMLDTDContent, HTTPURL и т. п., в которых не всегда может быть ясно, где заканчивается одно слово и начинается другое.
2.Недостатки сокращений
Рассмотрим минусы сокращений
1️⃣Неочевидность: например, что означает имя переменной res: resource, response или result? Если имя не очевидно, то программисты, читающие код, будут об него все время спотыкаться
2️⃣Сложность для новичков: когда в коде используется множество специфических сокращений, их значения приходится узнавать и запоминать. В большинстве проектов список допустимых сокращений отсутствует, поэтому их расшифровка превращается в угадайку. Это значительно усложняет адаптацию новых разработчиков (onboarding) и повышает порог входа в проект
3️⃣Неоднородность: программисты часто используют разные стили именования в проекте. В одном месте может быть msg, а в другом — message. Где-то num, а рядом — number. Это создает путаницу и усложняет поиск по коду, особенно в больших проектах
2️⃣Сложность для новичков: когда в коде используется множество специфических сокращений, их значения приходится узнавать и запоминать. В большинстве проектов список допустимых сокращений отсутствует, поэтому их расшифровка превращается в угадайку. Это значительно усложняет адаптацию новых разработчиков (onboarding) и повышает порог входа в проект
3️⃣Неоднородность: программисты часто используют разные стили именования в проекте. В одном месте может быть msg, а в другом — message. Где-то num, а рядом — number. Это создает путаницу и усложняет поиск по коду, особенно в больших проектах
3.Рекомендации по использованию сокращений
Если вы хотите использовать сокращения в своем коде, то придерживайтесь следующих правил:
1️⃣Будьте аккуратны: используйте только общепринятые сокращения или те, которые приняты в вашей команде. Не придумывайте собственные сокращения, которые понятны только вам
2️⃣Согласуйте стиль: договоритесь с командой, какие сокращения допустимы в вашем проекте, чтобы унифицировать кодовую базу
3️⃣Пишите код для людей: есть сомневаетесь в выбранном сокращении, лучше используйте полное слово. Краткость хороша, но не в ущерб читаемости кода
2️⃣Согласуйте стиль: договоритесь с командой, какие сокращения допустимы в вашем проекте, чтобы унифицировать кодовую базу
3️⃣Пишите код для людей: есть сомневаетесь в выбранном сокращении, лучше используйте полное слово. Краткость хороша, но не в ущерб читаемости кода
4.Часто используемые сокращения
Я сам активно использую сокращения и не вижу в этом проблемы, но считаю важным соблюдать баланс. Чтобы упростить вам выбор, какие сокращения применять, предлагаю свой список:
add → addition
app → application
auth → authentication
calc → calculate
cfg/config → configuration
curr → current
char → character
del → delete
dev → development
dir → directory
elem → element
env → environment
err → error
exec → execute
expr → expression
id → identifier
init → initialize
len → length
max → maximum
min → minimum
msg → message
num → number
req → request
resp → response
temp → temporary
util → utility
val → value
src → source
fmt → format
idx → index
obj → object
Заключение
Использование сокращений — это полезный инструмент, который помогает сделать код компактным и удобным для написания. Однако стоит помнить, что сокращения не должны ухудшать читаемость и понимание кода. Следуя рекомендациям и применяя сокращения из общего списка, вы сможете создать более структурированный, понятный и удобный для сопровождения код.
Автор: Чимаев Максим
Оцените статью, если она вам понравилась!