dev-rules/docs/regulations/layout.md at v2

1c/dev-rules

Fork 0

mirror of https://github.com/ones-devguide/dev-rules.git synced 2026-04-06 07:54:27 +02:00

Files

Vladimir Ochakovskiy 5a6aedb311 edit

2025-11-28 15:12:23 +07:00

7.7 KiB

Raw Permalink Blame History

sidebar_position, sidebar_label, title

sidebar_position	sidebar_label	title
4	Оформление	Оформление

Модули

Все модули (общие, формы, объекта, менеджера, команд) должны соответствовать стандартам:

Структура модуля
Поддержка толстого клиента, управляемое приложение, клиент-сервер (относится к модулю объекта и менеджера)
В доработанных типовых объектах наш код должен быть расположен в собственной области в низу модуля:
```
#Область ИмяКомпании

// Твой код

#КонецОбласти
```

Строки

При длине строки более 140 символов следует использовать переносы. Строки длиннее 140 символов делать не рекомендуется, за исключением тех случаев, когда перенос невозможен (например, в коде определена длинная строковая константа, которая выводится без переносов в окно сообщений с помощью объекта СообщениеПользователю).

Конкатенация строк может быть заменена на СтрСоединить или СтрШаблон

Вместо:

Процедура ВыводОшибки(НомерСтроки, ТипДанных)
    Результат = "Ошибка в данных в строке " + НомерСтроки + " (требуется тип " + ТипДанных + ")";
КонецПроцедуры

Использовать:

Процедура ВыводОшибки(НомерСтроки, ТипДанных)
    Результат = СтрШаблон("Ошибка в данных в строке %1 (требуется тип %2)", НомерСтроки, ТипДанных);
КонецПроцедуры

Имена методов и их описание

Стандарт 1С “Описание процедур и функций“
Стандарт 1C “Правила образования имен переменных“

Важно: Не использовать сокращения переменных подобных примеру:
Имена процедур и функций
Все методы программного интерфейса должны иметь описание.

Это единственный “контракт” между разработчиками касающихся типизации. Для быстрого создания описания есть специальная возможность в конфигураторе (После создания описание нужно убрать начальную часть Процедура / Функция):

Запросы

Оформление текстов запросов
Нужно стараться, чтобы каждая часть формируемого запроса могла быть открыта с помощью конструктора запросов

Метаданные

Читаемость кода

Избыточный верхний уровень условия Если...Тогда...Иначе

Для улучшения читаемости сделать условие в начале метода с выходом из метода с помощью Возврат.

Необязательный комментарий

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

Присутствует «мертвый» код, пустой обработчик

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

Проверка заполненности/пустоты коллекции

Для повышения читаемости проверку коллекции на заполненность/пустоту лучше выполнять через специальную функцию ЗначениеЗаполнено вместо использования сравнения количества коллекцию с нулем. Правило

Разделение на логические сегменты

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

Разделить выполнение и выборку/выгрузку результата запроса

Правильно разделять выполнение и выборку/выгрузку результата запроса.

Тексты запросов выносите в отдельные функции

Длинные запросы, больше обычной выборки с условием, стоит выносить в отдельную функцию. Код становится компактней, а для отладки текста запроса код модуля не нужен.

Непечатные символы

Обязательно включить отображение непечатных символов. ИТС: Отобразить непечатаемые символы

Выравнивание по символам делается с помощью пробелов. Нельзя использовать табы после первого значимого символа. В разных средах будет разъезжаться отображение.

Для облегчения рутины можно использовать инструмент для выравнивания ones-formatting.

Статья: Отступ с помощью табуляции, выравнивание по пробелам.

7.7 KiB Raw Permalink Blame History