№16 ПравилаЧистогоКода

1.

Правила чистого кода 1С

2.

План занятия
1
2
3
4
Общие правила оформления кода
Наименования, местонахождение и пр.
Функциональные правила
Запросы

3.

Введение
«Чистый код» - это код, написанный с
соблюдением
стандартов
и
рекомендаций
от
компании
«1С»,
который при этом легко читать и
поддерживать. Иными словами, практика
написания «чистого кода» позволяет нам
быстро исправлять, дорабатывать или
даже искать ошибки в своем или чужом
коде.

4.

Введение
Существует несколько уровней правил по написанию грамотного
кода:
• стандарты 1С
• стандарты заказчика
• стандарты внутри команды
• рекомендации 1С
Во многом стандарты команды и заказчика строятся на стандартах
1С, но существуют некоторые рекомендации, важность которых
разные программисты воспринимают по-разному. Следовательно
двумя важнейшими документами являются первые 2 стандарта.
Стандарт же внутри команды как правило описывает ситуации,
которые не описаны в стандарте заказчика.

5.

1 Общие правила оформления кода

6.

Общие правила оформления кода
- Код пишется на русском языке(исключение – всё
связанное с веб сервисами). В текстах модулей не
допускается использование буквы «ё» (исключение –
комментарии)
Хоть платформа и позволяет писать код на
английском языке, но общепринято чтобы
программисты использовали русский.
Исключениями являются базы для зарубежного
рынка

7.

Общие правила оформления кода
- Максимальная длина строки – 120 символов.
Проверить длину строки можно в нижнем правом
углу конфигуратора. Если длина строки превышает, то
необходимо перенести часть кода на следующую
строку

8.

Общие правила оформления кода
Примеры переноса текста

9.

Общие правила оформления кода
- Код необходимо разделять на логические модули символом ПС.
Вложенный код необходимо табулировать. (можно использовать
alt+shift+f)
Неправильно:
Правильно:

10.

Общие правила оформления кода
Табулированию не поддаются:
- Операторы «Процедура», «КонецПроцедуры», «Функция»,
«КонецФункции»;
- Заголовки (описания) процедур и функций;
- Операторы "раздела основной программы" (с учетом
синтаксического отступа);
- Директивы компилятора &НаКлиенте, &НаСервере и т.д.
- Инструкции препроцессора (в т.ч. #Область и #КонецОбласти )
Операторы «НачалоТранзакции» и «КонецТранзакции» в виду
своей особенности не требуют табуляции после себя.

11.

Общие правила оформления кода
- Если кода получается слишком много/появляется
повторяющийся код, то его необходимо разбить на
несколько процедур/функций
Данный шаг необходим для повышения читаемости
кода, упрощению навигации и упрощению в отладке
ошибок

12.

Общие правила оформления кода
- Удаляйте неиспользуемый/комментируемый код.
Лишний код и комментарии
мешают читаемости кода и
растягивает модуль.
Комментировать код
рекомендуется только в рамках
модификации его (то есть когда
вы заменяете старый код
новым)

13.

Общие правила оформления кода
Кстати немного о комментировании
- Каждый комментарий должен быть осмыслен
- Короткие комментарии можно оставлять в конце
строки (Перем = ЭтотОбъект // коммент )
- Большие комментарии пишутся в отдельной строке
перед текстом (как правило – короче 100 символов
в длину)
- Комментарии относятся к логическим блокам, так
что перед комментарем нужна пустая строка

14.

2 Наименования, местонахождение и пр.

15.

Наименования, местонахождение и пр.
- В одной функции/процедуре должен быть реализован
один функционал и название данной функции/процедуры
должно соответствовать этому функционалу
Неправильно:
- Процедура ЛеваяПроцедураДляВещи()
// загружает данные в таблицу, очищает массивы, выводит
сообщения пользователю
Правильно:
- Процедура ЗагрузкаФайловВТаблицуЗначений()
// загружает файлы в таблицу

16.

Наименования, местонахождение и пр.
- Наименование общих модулей также должно нести
осмысленный характер. То же касается и
наименований переменных в коде.
Неправильно:
- ОМ НужныеПроцедуры
- Уга = Новый Массив
Правильно:
- ОМ РаботаСФайлами
- ФайлыСФормы = Новый Массив

17.

Наименования, местонахождение и пр.
- У экспортных и глобальных процедур/функций
обязательно наличие описания.
Так как данные процедуры/функции могут использоваться
из практически любого места системы, то для повышения
эффективности нужно добавлять описание с входными и
(если есть) выходными параметрами.

18.

Наименования, местонахождение и пр.
- Не рекомендуется объявлять функцию/процедуру с более чем 7
параметрами.
Это очень сильно вредит читаемости кода и увеличивает
когнитивную нагрузку. Если существует острая необходимость
передать более 7 параметров, то следует использовать структуру.

19.

Наименования, местонахождение и пр.
- Наименование процедур должно состоять из глагола в
неопределенной форме. Наименование функций наоборот не
должно содержать сказуемых
Сделано это для того чтобы программист мог быстрее осознать
разницу между вызываемыми процедурами/функциями. (например
при вызове общего модуля чтобы можно было определять что
возвращает значение, а что – нет)
Неправильно: Функция ЗагрузитьФайлы() Процедура ТаблицаЗнч()
Правильно: Функция ОбработанныеФайлы() Процедура ЗаполнитьТаблицуЗначений()

20.

Наименования, местонахождение и пр.
- В названиях реквизитов объектов должны отсутствовать имена
метаданных (Например справочник, документ, перечисление и т.д.)
То есть нельзя создать регистр сведений, в котором
наименование измерения будет «Документ». Если в РС или в другом
объекте есть только один реквизит (Не наименование), то его
следует назвать «Объект»

21.

3 Функциональные правила

22.

Функциональные правила
- Не рекомендуется использовать «НайтиПоНаименованию»
Мало того, что данный метод не всегда может вернуть
правильное значение, так и ещё по своей сути это просто
максимально урезанный запрос. Лучше всего использовать запросы,
так как в них можно прописать сложную логику, которую иначе бы
пришлось писать кодом.

23.

Функциональные правила
- Одна клиентская процедура – один серверный вызов.
Считается неправильным многократный вызов серверного
модуля из клиентского. В таком случае лучше объединить
серверный функционал и делать его вызов однократным в рамках
одной клиентской процедуры.
Также неправильно делать несколько подряд идущих
клиентских процедур, каждая из которых будет обращаться к
серверу.

24.

Функциональные правила
- Недопустимо использование нескольких ссылочных вызовов.
При обращении к реквизиту объекта, который является
ссылкой на другой элемент (например, справочника), программа
загружает в память все значения реквизитов этой ссылки. С точки
зрения
эффективности
хранения
временных
данных
это
совершенно неверно. Поэтому нужно избегать подобных ситуаций
либо используя БСП (библиотеки стандартных процедур), либо
пользоваться запросом.
Неправильно: ЭтотОбъект.Склад.Местоположение.Наименование

25.

Функциональные правила
- Более вероятное условие в конструкции «Если» нужно ставить
впереди.
Система не глупая, поэтому если у вас условие типа «Если А и
Б и В», то при отрицательном значении «А» система не будет
проверять другие условия.
Пример:
Если ЗначениеЗаполнено(Тип) И Тип = Перечисления.Типы.ТипА
Здесь если бы мы поставили второе условие первым, то
получили бы ошибку выполнения внутреннего языка, поскольку
переменная Тип не всегда может быть заполнена

26.

Функциональные правила
- Не следует использовать метод «Сообщить».
Метод сообщить - это отголоски предыдущих версий платформы.
Метод сообщить не привязан к форме, в отличии от сообщения пользователю.
Более подробно можно ознакомиться здесь:
http://курсы-по-1с.рф/articles/вывод-сообщений-пользователю/
Вместо него следует использовать:
1) Если есть БСП, то методы БСП СообщитьПользователю
2) Если нет БСП, то “новый СообщениеПользователю”
Со временем, метод “Сообщить” будет удален из платформы.
В случае отказа, придется переписать использование "Сообщить" на
"СообщениеПользователю". Поэтому необходимо сразу использовать последний
вариант.

27.

Функциональные правила
- Недопустимо получать значение реквизита от “Ссылки”
При обращении к ссылке через точку, в память подгружается ВЕСЬ объект, что чрезмерно нагружает
систему. Необходимо получать исключительно необходимые реквизиты используя БСП или запрос.

28.

4 Запросы

29.

Запросы
- Недопустимо использование запроса в цикле.
За это согласно статье УК РФ №59 безоговорочно назначается
смертная казнь.
А если без шуток, то многократное выполнение одно и того же
запроса в цикле занимает гораздо больше времени, чем
выполнение одного запроса. А поскольку итераций циклов и данных
в системе со временем будет всё больше, то нагрузка на
производительность будет очень быстро расти.
Избежать этого поможет выгрузка всех записей по общему
признаку в таблицу значений и последующая работа с ней (нельзя
запрос в цикле, но можно отбор в ТЗ в цикле)

30.

Запросы
- Следует минимизировать объем выборки запроса
Лишние поля и данные в запросе тоже не к чему получать.
Особенно неправильным делать это если далее идёт обработка
выборки, но при этом не все поля используются.

31.

Запросы
- Не рекомендуется делать неявные запросы
Пример неявного запроса:
Где неявно участвует справочник Товары

32.

Запросы
- Виртуальной таблице всегда при возможности нужно передавать
параметр(не путать с условием)
Предположим что мы хотим получить из РС(Срез последних)
все актуальные записи. Если мы пропишем условие в секции
«Условия», то платформа сначала получит все записи, а затем
избавится от неугодных. Но если прописать это в параметрах
виртуальной таблицы, то тогда платформа изначально будет
отбирать только нужные записи. Таким образом значительно
повышается скорость работы запроса.

33.

Запросы
Недопустимо использование “каскадного” соединения:
Каскадное соединение - соединение,
когда с результатом соединения двух
таблиц соединяется третья.
Почему это плохо?
После
выполнения
первого
соединения на СУБД, построитель не
может предположить его результат,
соответственно
не
знает,
как
правильно построить план запроса.
Из-за этого может быть выбран не
оптимальный план, что увеличит
время выполнения.
Как исправить?
Результат
первого
соединения
положить во временную таблицу, и
уже временную таблицу объединить с
третьей.

34.

Запросы
Недопустимо соединять таблицы с виртуальными таблицами:
Виртуальная таблица “строиться” на СУБД в
момент обращения к ней, т.е. выполняется
соединение нескольких таблиц. Т.е. при
соединении виртуальной таблицы и еще какойто, будет выполняться “каскадное” соединение,
а как вы знаете из предыдущего пункта использование “каскадных” соединения
категорически не допускается.

35.

Запросы
Если в секции “ГДЕ” необходимо использовать “ИЛИ”, то вместо его
использования требуется переписать запрос с использование
“ОБЪЕДИНИТЬ/ОБЪЕДИНИТЬ ВСЕ”.
Обусловлено это использованием индексов
для ускорения чтения информации из СУБД.
При использовании “ИЛИ” в условии индексы
не будут использоваться, что повлечет за
собой замедление выполнения запроса.
Выбор использования “ОБЪЕДИНИТЬ” или
“ОБЪЕДиНИТЬ ВСЕ” зависит от того, могут ли в
результате объединения повторяться строки
или нет.
Подробнее про это можно прочитать в 434
стандарте на ИТС.
#std434

36.

Запросы
Если после выполнения запроса, вам требуется обработать результат
выборки, и при этом нет прямой необходимости получать Таблицу
Значений, то выборку нужно обходить с использованием конструкции
“Пока Выборка.Следующий() Цикл”. Так как, если запрос будет пустой, то
ошибки при обращении Выборка.КакоеТоПоле не возникнет. В то же
время,
если
выполнить
Выборка.Следующий(),
а
затем,
Выборка.КакоеТоПоле, то в случае, если выборка окажется пустой,
пользователь увидит ошибку выполнения встроенного языка.

37.

Стандарты
Ссылки: https://its.1c.ru/db/v8std/content/000/hdoc где 000 - номер стандарта
Номера:
456 Тексты модулей
444 Перенос выражений
437 Оформление текстов запросов
453 Описание процедур и функций
441 Общие требования к построению конструкций встроенного языка
454 Правила образования имен переменных
647 Имена процедур и функций
474 Имя, синоним, комментарий
550 Имена объектов метаданных в конфигурациях
488 Стандартные роли
470 Использование функциональных опций

38.

Заключение