Добрый день. Вот интересно стало - у кого какое отношение к использованию Null как литерала, т.е. в коде? На ИТС вроде не встречал каких-то ограничивающих моментов. Но сам считаю - что поняте Null - это исключительно для работы в запросе, причем обрабатывать Null поля нужно сразу при их возникновении.
Само наличие Null как литерала считаю неким атавизмом, редко применяемым и существующем "на всякий случай" - как метки например.
Неоднократно сталкивался с его (на мой взгляд) глупым (мягко говоря) применением - может я чего не понимаю?

Вот случаи, с которыми сталкивался:
1) Получается таблица значений из СКД (т.е. формируется в коллекцию), дальше следует такое условие:
Если тз.Количество() = 0 ИЛИ (тз[0].Ресурс1 = NULL И тз[0].Ресурс2 = NULL И ..... тз[0].Ресурс16 = NULL) Тогда Возврат КонецЕсли;

2) Чел делает план-фактный отчет. Как делаю такие вещи я: две ВТ (набор измерений и ресурсов - одинаковый) - одна план, другая - факт. Объединяем, сворачиваем, смотрим отклонения. Но он сделал через полное соединение, а потом через "ЕСТЬ NULL" определял где план, где факт, и от этого как-то плясал. Ладно бы только это. В выходных полях пишет:
Если <Какое-то условие> ТОГДА 0 ИНАЧЕ NULL КОНЕЦ
, а потом идут свертки таблиц.

Все это примеры нереально нечитабельного кода и запроса - на мой взгляд. Но  может я чего не понимаю? Вот опять столкнулся с применением Null в коде - пихают в структуру. Зачем это извращение, если есть неопределено?

(0) NULL это не значение. Логичней конечно бы было запретить такие сравнения во встроенном языке, а вместо этого ввести использование функции Есть null, как в языке запросов. Использование подобных конструкций, как в типовых конфигурациях, так и в документации остается на совести разработчиков, которые как и мы действуют по принципу "все, что не запрещено, то разрешено".

(0) А реально есть в типовых такое?..

(3) -> (2)

Так, два кота уже есть.
Ждём ещё.

(5) он забанен Ненавижу 1С

(3) вот поиск по типовой бухне http://screencast.com/t/6ZswvjR3yxor

ппц, как-то даже и не думал поиском по типовой пройтись, казалось настолько своеобразный момент, что...

Хотя вот с таким использованием я бы согласился:

    Запрос = Новый Запрос;
    Запрос.Текст =
    "ВЫБРАТЬ
    |    МАКСИМУМ(Замеры.ДатаЗаписи) КАК ДатаЗамера
    |ИЗ
    |    РегистрСведений.ЗамерыВремени КАК Замеры";
    Выборка = Запрос.Выполнить().Выбрать();
    Если Выборка.Следующий() И Выборка.ДатаЗамера <> Null Тогда
        ВерхняяГраньДатыЗамеров = Выборка.ДатаЗамера;
    Иначе
        Возврат;    
    КонецЕсли;

(8) странный код, то есть если в выборке есть хоть одна незаполненная дата то ничего не делаем...
Надо помнить одно существенное различие - в запросе сравнение с NULL всегда дает ложь, даже с литералом NULL, именно для этого ввели функцию Is Null.
А в коде сравнивай сколько влезет, но ИМХО Null не должен из запроса проваливаться в код, обычно на месте Null ставят пустое значение типа колонки или НЕОПРЕДЕЛЕНО, если тип составной.

(9) в (8) - в выборке в результате всегда будет только одна запись, даже если РС пустой. Это особенности агрегирующих функций - запись будет всегда. Потому-то я и согласен - тут либо в запросе вводить вложенный запрос, и сравнивать выходные поля, либо обрабатывать результат. В последнем случае меньше писанины и выше читабельность.
"Null не должен из запроса проваливаться в код, обычно на месте Null ставят пустое значение типа колонки или НЕОПРЕДЕЛЕНО, если тип составной." - как по мне, это вообще должно быть в ИТС-е вписано. Но нет там ничего подобного(
Просто если тыкать кого-то носом - то опираясь на некий регламент. А тут - субъектив какой-то получается. Особенно жалко людей которые пришли практически нулевыми, и УЧАТСЯ на вот таком вот коде - который в (2) приведен.

* Особенно жалко людей которые пришли практически нулевыми, и УЧАТСЯ на вот таком вот коде - который в (1) приведен.

Например, запрос с внутренним соединением, стоит задача в случае если левая часть соединяемых таблиц есть, правой нет, выводить сообщение об ошибке пользователю, меняем соединение на левое, делаем в коде условие на NULL с сообщением об ошибке.
Другая задача, тз с колонкой счет и колонками - субконто, субконто для конкретного счета может быть незаполнено, а может вообще отсутствовать, используем для незаполненых субконто неопределено, для отсутствующих NULL. Можно конечно использовать типизированные пустые значения и неопределено, но субконто могут быть составными + у типизированных пустых значений проблема с отборами, проблематично отобрать все пустые субконто, если у них разные типы.