Зачем в коде 1С используют конструкции «Если Истина Тогда» и «Если Ложь Тогда»?

← На главную

Разбирая чужой код прошлых лет, многие разработчики сталкиваются с загадочными логическими условиями, которые на первый взгляд не имеют никакого смысла. Речь идет о блоках Если Ложь Тогда и Если Истина Тогда. Проанализируем, зачем программисты применяли эти приемы, какие задачи они решали и как правильно реализовывать подобный функционал в современных реалиях платформы 1С:Предприятие 8.

Конструкция «Если Ложь Тогда»: хак для контекстной подсказки

Рассмотрим первую конструкцию. Ранее она массово применялась для того, чтобы заставить конфигуратор 1С выводить контекстную подсказку (свойства и методы) для параметров функций или процедур, тип которых системе был изначально неизвестен.

Посмотрим на пример такого кода:


Процедура ОбработатьДокумент(Док)
    Если Ложь Тогда
        Док = Документы.ПоступлениеДопРасходов.СоздатьДокумент();
    КонецЕсли;
    
    // Далее при наборе "Док." конфигуратор будет предлагать реквизиты документа
    Док.Комментарий = "Обработано";
КонецПроцедуры

В этом случае код внутри условия никогда не выполнится (так как условие всегда ложно), но синтаксический анализатор старого конфигуратора считывал это присвоение и «понимал», какой тип имеет переменная Док.

Улучшенный вариант из прошлого:

Некоторые программисты модифицировали этот подход, чтобы фиктивный код вообще не компилировался. Для этого использовали директивы препроцессора:


#Если Сервер И Не Сервер Тогда
    Док = Документы.ПоступлениеДопРасходов.СоздатьДокумент();
#КонецЕсли

Этот вариант был лучше, так как платформа вырезала данный кусок текста на этапе чтения модуля, и он не попадал в итоговый исполняемый код.

Современный подход к типизации переменных

Сегодня использование фиктивных логических условий для подсказки считается плохим тоном. В современных инструментах разработки, таких как 1C:Enterprise Development Tools (EDT) или при использовании VS Code с плагином BSL Language Server, эта задача решается штатными комментариями. Разберем правильный подход:

Использование формализованных комментариев платформы: // Тип: ДокументСсылка.ПоступлениеДопРасходов
Использование стандарта JSDoc: // @type DocumentRef.ПоступлениеДопРасходов

Среда разработки автоматически считывает эти комментарии и включает полноценную контекстную подсказку без добавления «мусорного» исполняемого кода.

Конструкция «Если Истина Тогда»: сворачивание кода

Теперь проанализируем второе чудо мысли. Конструкция Если Истина Тогда применялась в версиях платформы 8.2 и ниже, когда в конфигураторе еще не было встроенного механизма группировки произвольных строк кода. Это было необходимо для визуального структурирования длинных алгоритмов (например, при сложной генерации XML).

Посмотрим на пример того, как это выглядело:


Если Истина Тогда // Узел документ
    Если Истина Тогда // Узел Поставщик
        // код формирования поставщика...
    КонецЕсли;
    Если Истина Тогда // Узел Покупатель
        // код формирования покупателя...
    КонецЕсли;
КонецЕсли;

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

Современная альтернатива: Директивы областей

Начиная с версии 1С 8.3, потребность в таких костылях полностью отпала. Появились штатные директивы препроцессора для группировки кода. Заменим наш пример на современный стандарт:


#Область УзелДокумент
    
    #Область УзелПоставщик
        // код формирования поставщика...
    #КонецОбласти
    
    #Область УзелПокупатель
        // код формирования покупателя...
    #КонецОбласти

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

Использование директив #Область и #КонецОбласти сейчас является единственным официально рекомендованным стандартом (согласно правилам ИТС) для структурирования модулей.

Почему сегодня эти конструкции — строгий антипаттерн?

Разберем по шагам, почему от привычек прошлого нужно избавляться:

Влияние на компиляцию: В отличие от директив препроцессора, конструкция Если Ложь Тогда является исполняемой. Она строится в абстрактное синтаксическое дерево (AST), увеличивает объем скомпилированного модуля и заставляет сервер тратить микроресурсы на оценку булева выражения.
Статический анализ кода: В enterprise-разработке сейчас повсеместно применяются инструменты автоматической проверки качества кода (SonarQube, BSL). Современный анализатор моментально пометит Если Истина Тогда как «Мертвый код» или «Использование константного выражения в условии». Модуль просто не пройдет проверку (Quality Gate) при попытке поместить его в хранилище или Git.
Проблема «зомби-кода»: Использование фиктивных условий для сохранения «на будущее» кусков старого алгоритма прямо нарушает принципы Clean Code. Если код не используется — его нужно удалить. Если он понадобится снова, вы всегда сможете восстановить его из истории версий хранилища.

Таким образом, встретив в старых модулях подобные конструкции, смело заменяйте их на современные комментарии типизации и директивы областей. Это сделает ваш код чище, понятнее и профессиональнее.