← На главную

При написании программного кода на языке 1С разработчики часто сталкиваются с дилеммой: как более грамотно и читаемо записать условие отрицания? Выбор между конструкциями <> и НЕ кажется незначительным, однако именно такие детали определяют качество и поддерживаемость вашего кода. Давайте вместе разберем, какие подходы считаются стандартом и почему это важно.

Разберем варианты написания условий

Рассмотрим два популярных способа написания условия:

1. Вариант с использованием оператора «не равно» (<>):
   Скопировать код

   
   Если ВидОперации <> Перечисление.Значение Тогда
       // Выполняем действия
   КонецЕсли;
   

2. Вариант с использованием логического отрицания (НЕ):
   Скопировать код

   
   Если НЕ ВидОперации = Перечисление.Значение Тогда
       // Выполняем действия
   КонецЕсли;
   

С точки зрения производительности платформы 1С:Предприятие, разница между этими двумя записями практически отсутствует. Интерпретатор кода приводит оба выражения к идентичному результату, поэтому попытки оптимизировать код на уровне микросекунд при выборе между <> и НЕ не принесут ощутимого прироста скорости работы системы.

Почему <> — предпочтительный вариант

Основным критерием выбора в современной разработке является читаемость кода. Когда мы пишем Если ВидОперации <> Перечисление.Значение, наш мозг считывает условие как «Если вид операции не равен значению». Это прямое соответствие естественному языку.

В случае с конструкцией Если НЕ ... = ..., разработчик вынужден совершить «двойное логическое действие»: сначала мысленно представить условие равенства, а затем инвертировать его. Это повышает когнитивную нагрузку, особенно если условие находится внутри сложной логической цепочки.

Когда использование НЕ является оправданным

Несмотря на то, что для сравнения значений мы рекомендуем использовать <>, есть ситуации, когда оператор НЕ становится эталонным решением:

1. Работа с типами Булево: Если у вас есть переменная, которая сама по себе является логическим флагом (например, Проведен, Заполнен, Выполнен), использование конструкции НЕ является стандартом.
   Скопировать код

   
   Если НЕ ДокументОбъект.Проведен Тогда
       Сообщить("Документ не проведен!");
   КонецЕсли;
   

2. Группировка сложных логических выражений: Если в условии используется длинная связка из И и ИЛИ, применение НЕ ко всей группе через скобки позволяет избежать чрезмерной сложности и не требует применения законов де Моргана, что делает код более понятным.

Рекомендации по чистому коду

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

• Избегайте отрицаний в именах переменных: Не стоит называть переменные как НеЗаполнен или НеВыполнено. Это создает риск «двойного отрицания» (например, Если НЕ НеЗаполнен), в котором очень легко допустить логическую ошибку. Используйте позитивные названия (Заполнен, Выполнено) и инвертируйте их через НЕ в коде.
• Соблюдайте единообразие: Если в вашем проекте или команде уже принят определенный стиль написания условий, старайтесь придерживаться его. Необязательные правки стиля «под себя» вносят лишний шум в историю изменений (Git) и усложняют процесс Code Review.
• Минимизируйте вложенность: Старайтесь строить условия так, чтобы иметь возможность раньше выйти из цикла или функции с помощью операторов Продолжить или Возврат. Часто использование <> позволяет написать более компактную проверку и избавиться от лишнего вложения Если.

Подводя итог, можно сказать: в большинстве случаев при сравнении значений выбирайте оператор <>, так как он обеспечивает максимальную наглядность. Оставьте НЕ для работы с логическими переменными и сложными составными условиями. Помните, что чистота кода — это прежде всего забота о том, кто будет читать вашу программу после вас.