Я буду употреблять слово «Функция», но под этим буду иметь в виду «Функции» и «Процедуры».
Большинство статей по оформлению кода это описание комментариев, заголовков функций и нумерации обработок. Но разве на этом заканчивается правила написания чистого кода? Вам будет важно, кто написал код, если это процедура на 5000 строк, которая делает «всё»? Ну если только для того, чтобы проклясть этого человека, да и дата написания кода вам не особо поможет. А что же тогда важно? По моему мнению, это читаемость и простота отладки. Не будем сейчас разбирать правильность и скорость выполнения, а поговорим только об оформлении.
Существует 10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками и, взяв 2 за отправную точку, я вывел для себя следующие правила написания кода для 1С.
- Одна функция – одно действие. Это убирает задвоение кода (на практике я встречал сокращения строк кода после рефакторинга в 3 раза!) Это позволяет использовать функции повторно, а не каждый раз заниматься написанием заново.
- Размещать функции там, к чему функция относятся. То есть не надо все функции стараться запихнуть в один модуль. Чем точней вы будете размещать функции, тем чаще вы будите их находить и использовать повторно. Если функция относится к документу реализации, то надо ее размещать в менеджере реализации. Так вы будете чаще находить уже готовые функции, даже если забыли, что их когда-то писали.
- Делите общие модули по логике работы. Почти то же самое, что и пункт 2, но про общие модули. Не надо делать модуль с именем "Разное" или "Общее". Называйте их "РаботаСТабличнойЧастьюДокументов", "ЗагрузкаДанныхFTP" и не надо бояться модулей в одну функцию, придет время и вы его расширите, да если даже и нет, зато не будет бардака в других модулях.
- Не называйте функции «от балды». Называйте максимально однотипно, например я взял следующий формат. Все функции должны начинаться с глагола и обязательно содержать в наименовании тип данных, с чем производится действие. («Заполнить», «Получить», «Найти» и т.д.) + («Документ», «Справочник», «Структура», «ТаблицаЗначений» и т.д.). Это позволит быстрей читать свой же код, а не раздумывать на тему, что я имел в виду, когда назвал функцию "БыстроСпрВ(до)"
- Специально для не любителей «НЕ» и «<>» в условиях. Где-то я встречал рекомендацию, и она мне понравилась: В условиях первая группа команд та, которая чаще выполняется. Так код смотрится читабельней.
- Результат условия в одну команду пишите одной строкой. Самое частое, где я это использую, это когда после ТОГДА идет только ВОЗВРАТ; или ПРОДОЛЖИТЬ;. Исключение если есть ИНАЧЕ или ИНАЧЕЕСЛИ.
Когда растягивают короткое условие на 3 (иногда 5) строк. Читабельность это только ухудшает.
-
Тексты запросов выносите в отдельные функции. Длинные запросы, больше обычной выборки с условием, стоит выносить в отдельную функцию. Код становится компактней, а для отладки текста запроса код модуля не нужен.
-
Удаляйте ненужный код. Я, конечно, понимаю, что удалять код, который вы писали многие часы, жалко, но оставлять простыни зеленого кода тоже не стоит, особенно когда между двумя простынями есть одна не закомментированная строка, а за оставление не использованных функций без комментирования, считаю, надо лишать прав на программирование.
-
Не комментируйте каждую строку. Код должен быть легко читаемый и без комментариев. Писать комментарии стоит только у правда сложных алгоритмов, а излишнее комментирование только усложняет.
-
Описание обязательно делайте у экспортных или глобальных функций. Это сильно вам поможет при вторичном использовании. У остальных функций по желанию, я это делаю, только если приходит что-то сложное.
-
Объединяйте множество параметров в структуры. Если вам надо получить/передать более шести параметров в функцию, то лучше создать Структуру и передать их в ней (или часть параметров передать в структуре), и не забыв сделать описание этой структуры в описании.
-
Объявляйте переменные в начале функции. 1С позволяет объявлять переменные в любом месте кода и инициализировать сразу, но для чтения удобней, когда они все объявляются и инициализируются в самом начале. Тогда сразу видно, какие параметры приходят в функцию, и какие переменные используются внутри.
-
Собирайте строки в переменные. Не стоит собирать строки сразу при заполнении реквизита или вызове метода. Сделайте это в отдельной переменной и присвойте, а еще лучше в отдельной функции, но это уже в зависимости от сложности. Это спасет вас от длинных строк вызовов.
- Возврат значений в функциях делайте одного типа. Если Функция возвращает объект, то она должна возвращать или объект или пустую ссылку (иногда можно Неопределено). Если функция возвращает коллекцию, то она всегда должна возвращать коллекцию. Это спасет вас от разных ошибок при обработке результата выполнения этих функций. (автор идеи ksely)
- В функциях стараться размещать "Возврат" в конце. Конечно это правило далеко не всегда выполнимо, но если функция это допускает, то лучше это правило выполнять. Это вам поможет при отладке, когда мельком глянув текст и поставив точку остановки вы сразу на неё попадете.
P.S. Буду обновлять, если что-то понравится из комментариев или вспомнится.
