digital-garden/dev/efficiency/Соглашение о наименовании.md
Struchkov Mark 320a20c2b4
Some checks failed
continuous-integration/drone/push Build is failing
Обновление
2024-11-24 11:44:57 +03:00

38 lines
5.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
aliases:
- осмысленные имена
- соглашений о наименовании
- правила именования
tags:
- maturity/🌱
date: 2024-11-24
---
Одним из важнейших аспектов [[Чистый код|чистого кода]] является соблюдение правил именования. Понятные и согласованные имена позволяют улучшить читаемость и поддержку вашего кода. Рассмотрим несколько ключевых принципов:
## Соблюдайте соглашения стиля
Используйте общепринятые соглашения стиля для вашего языка программирования. Например, `camelCase` для переменных и методов, а `PascalCase` — для классов. Соглашения стиля могут варьироваться в зависимости от проекта или команды, и важно придерживаться общепринятых правил в данной среде. ==Важно соблюдать единообразие в стиле, чтобы упрощать навигацию по коду и снижать [[Снижение когнитивной нагрузки при разработке|когнитивную нагрузку]].==
## Выбирайте описательные имена
Чем точнее имя, тем легче понять назначение функции или переменной. Например, если функция конвертирует валюты, дайте ей имя, которое явно указывает на её назначение, а не абстрактное название вроде `convert`.
Описательные имена облегчают понимание и поддержку кода, но важно сохранять баланс между описательностью и длиной имени, чтобы избежать чрезмерно длинных названий. Описательные имена облегчают понимание и поддержку кода.
## Избегайте двусмысленных названий
Избегайте абстрактных названий, которые могут вызвать неясности. Например, если работаете с валютами, используйте явные обозначения, такие как `usdToEur`, чтобы избежать путаницы с другими типами долларов (США, Австралии, Канады и т.д.). Также рекомендуется использовать общеизвестные аббревиатуры для валют, если это делает код короче и при этом понятным.
## Используйте произносимые имена
Не сокращайте названия переменных до непонятных сокращений, вроде `cstmrLst`, когда можно использовать `customerList`. Это снижает [[Снижение когнитивной нагрузки при разработке|когнитивную нагрузку]] и делает код более доступным для чтения. Использование полных слов также помогает при устном обсуждении кода в команде.
## Избегайте магических чисел
Если в вашем коде присутствуют числовые значения, например коэффициент `0.9` для какой-либо операции, не вставляйте его напрямую. Определите его как константу, например, `CONVERSION_RATE = 0.9`, и используйте это имя в расчетах. Такой подход делает код более понятным и облегчает его поддержку, а также помогает избежать ошибок при изменении значений в будущем. Использование констант также облегчает автоматическое документирование и улучшает понимание кода новыми разработчиками.
## Чтение кода должно быть легким
Читатели вашего кода должны сосредотачиваться на логике, а не пытаться расшифровать странные имена переменных и функций. Чем понятнее ваш код, тем проще его поддерживать и развивать. Также рекомендуется использовать [[Комментарии в коде|комментарии в коде]], если имена переменных или логика могут быть неочевидными.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
**Родитель**:: [[Чистый код]]
**Источник**::
**Создана**:: [[2024-11-24]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->