Часто при написании программного кода возникает вопрос: нужно ли обязательно ставить точку с запятой перед закрывающими конструкциями, такими как КонецЕсли, КонецЦикла или КонецПроцедуры? На первый взгляд кажется, что если код работает без нее, то и ставить этот символ необязательно. Давайте разберем по шагам, на что влияет точка с запятой, проанализируем синтаксические особенности платформы и выясним причину, по которой стандарты разработки настоятельно рекомендуют ее использовать.
Для начала рассмотрим техническую сторону вопроса. Встроенный язык 1С (как и язык Pascal, элементы которого прослеживаются в 1С) использует символ точки с запятой именно как разделитель между исполняемыми операторами, а не как обязательный завершитель строки.
Конструкции языка КонецЕсли, КонецЦикла, КонецПроцедуры и КонецФункции официально являются не операторами, а операторными скобками. С точки зрения компилятора, у самого последнего оператора в блоке, непосредственно перед закрывающей скобкой, точку с запятой можно законно опустить. Платформа не выдаст синтаксической ошибки, и алгоритм выполнится корректно.
Посмотрим на пример такого кода:
Если Условие Тогда
Оператор1;
Оператор2 // Здесь точка с запятой пропущена, но код работает
КонецЕсли;
С точки зрения синтаксиса, такую конструкцию можно считать допустимой. Язык позволяет писать и несколько команд в одну строку, но в этом случае наличие ; между ними уже строго обязательно (например, А = 1; Б = 2;).
Если синтаксис допускает пропуск символа, почему же официальные методические материалы и опытные разработчики рекомендуют всегда его ставить? Проанализируем ситуацию с позиции сопровождения кода.
Главная проблема кроется в последующей доработке алгоритмов. Когда вы или другой программист вернетесь к этому коду спустя время, чтобы добавить новые строки, отсутствие разделителя приведет к обидной и иногда неочевидной синтаксической ошибке. Разберем логику:
Таким образом, целенаправленный отказ от точки с запятой перед операторной скобкой создает потенциальную проблему на ровном месте. Наличие символа делает код более надежным и готовым к масштабированию.
В эпоху развития механизма расширений в 1С отсутствие точки с запятой превратилось из вопроса "красоты" в реальную техническую проблему. Рассмотрим подробнее заимствование процедур с аннотацией &Вместо и использованием директив контроля.
Если в типовой конфигурации разработчик оставил строку без точки с запятой перед КонецЕсли, а вам необходимо добавить свой код сразу после этого оператора с помощью расширения, вы столкнетесь с серьезными неудобствами. Посмотрим на пример, как это будет выглядеть в расширении при вставке кода:
Если Условие Тогда
Оператор1;
Оператор2
#Вставка
; // Нам приходится "добивать" чужой оператор точкой с запятой
МойНовыйОператор;
#КонецВставки
Иначе
Оператор4;
КонецЕсли;
Либо, если вы используете метод #Удаление и #Вставка, вам придется заимствовать исходную строку, помещать ее в удаление и дублировать во вставке, добавляя недостающий разделитель. Это сильно усложняет чтение кода, увеличивает его объем и повышает вероятность конфликтов при обновлениях типовой конфигурации.
Помимо встроенного языка программирования, важно помнить про язык запросов 1С. Если в программном коде платформы пропуск ; перед скобкой прощается, то при написании пакетных запросов этот символ критически важен. Там он выступает строгим разделителем между отдельными текстами запросов внутри одного пакета. Его отсутствие полностью сломает логику выполнения пакета.
Интересно также упомянуть язык "1С:Исполнитель". В этом современном кроссплатформенном синтаксисе разработчики пошли еще дальше и полностью отказались от слов КонецЕсли или КонецЦикла. Там именно символ ; взял на себя роль закрывающего элемента группировки инструкций.
Обобщим все сказанное. Технически платформа простит вам пропуск точки с запятой перед операторными скобками, однако мы настоятельно рекомендуем всегда использовать этот символ. Это не просто дань уважения коллегам-разработчикам, но и страховка от потери времени при рефакторинге, доработках и, самое главное, при использовании расширений с контролем изменений. Пишите код так, чтобы его было удобно поддерживать и расширять!