Подскажите, какой оператор предпочтительнее использовать для сравнения?
1) Не Переменная1 = Переменная2
ИЛИ
2) Переменная1 <> Переменная2
Когда-то слышала, что предпочтительнее (1), но почему - не помню, и сейчас не могу информацию найти на эту тему.

Без разницы.

(0) Предпочитаю "<>", по мне так легче воспринимается.

Без фотки разницы нет)

Тут нужно просто включить мозг.
НЕ А=А будет работать как оператор сравнения, который даст нам булево и мы будем его "Переворачивать" оператором Если.

А <> А даст нам тоже булево, но его будет просто проверять оператор Если.

А реально пофиг.

Есть подозрение, что на <> требуется одна операция, а на НЕ равно - две.

Самое правильное это

НЕ А<>А=Ложь

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

от себя рекомендую http://1c.chistov.pro/2012/11/1.html от @{Groovy}

(7) Благодарю!

(0) В первом случае не надо переключать клавиатуру.

(7) Я, кстати, под мак сделал раскладку, жду выхода нативного клиента :)

(7) Открой для себя автозамену
бю      <>
б=      <=
ю=      >=
н       Неопределено
л       Ложь

и пр.

(4) я тоже так думала, по логике так и есть, но вспомнила, что говорили, что лучше (1), вот и пытаюсь выяснить почему.
но вы меня убедили в обратном.
мне нет проблем переключить раскладку,  а вот код должен работать как можно быстрее. так что буду писать <>

(11) http://1c.chistov.pro/2013/09/83_15.html

(10) добавь в раскладке альтэнтер

для перевода строки + |

(12) Это не ускорит код

(12) Скорость современных процессоров сводит на нет вашу оптимизацию. Сейчас, на выяснение того как быстрее,  вы потратили времени больше, чем выиграйте за всю вашу жизнь используя <> вместо НЕ.

(11) это те, которые по контрол-ку работают?

(12) Для прикладных программ главное свойство, это сопровождаемость, а скорость исполнения важна в отдельных узких местах.

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

(14) Пришли почтой, боюсь забыть. мыло -> павел тварь chistov.pro

(20) и к тому же это все надо не один раз в день проверять

(22) Поверьте, в конфигах есть +100500 мест, где действительно стоит задуматься над производительностью. А ваш вопрос совсем не тот случай.

(22) Лучше посмотри, как бы уменьшить нажатия клавиш и мишки у пользователей.

(20) Это не доли, это 10^-42 000 000 00 секунды умноженной на количество ядер проца.

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

(25) о_0

(0) тоже читал про такое, не могу вспомнить где и почему. <> использовать стал редко, только если конструкция тяжелая

Несколько лет назад, была такая же тема, и там решили что с НЕ будет быстрее, тем быстрее <>. Вообще с вопросами скорости и производительности на мисте часто ошибаются, спросить конечно полезно, но лучше всегда проверить самим.

(27) Запросы оптимизируйте. Смотрите планы запросов.

(26) Для этого есть замер производительности. Ускоряй там, где долго работает, а сравнение оставь.

+(29)*теперь быстрее <>

(25) Это да, но такие вещи всё равно лучше знать.

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

(34) А потом, что только в отладчике

Пятнично...

В курсе Гилева сказано, что "НЕ = " быстрее чем "<>" в случае сравнения составных типов. Я собственно поэтому никогда <> и не использую.
А никто не натыкался на неадекватное понимание компоновкой условий типа "Где Документ.Проведен"?

(28) вот и я так же

(29) не могу найти эту тему

(30) и это тоже делаю (предыдущая тема)

(0) Для 1-го варианта не надо раскладку переключать.

(37) да, вот оно!!!
а почему именно при составном?

(11) А если надо бю надбрать?

(0) Побоку.

(12) Не хочу огорчать, но скорость - это не стихия 1С. Для скорости надо использовать компиляторы.

(43) Встречал где-то такое слово?
И можно после ввода нажать стрелку вправо

(46) бюрократия <> <>рократия ))

(43) После пробела срабатывает. (47) Не надо тут ляля :)

Для чистоты, нужно прикрутить голосовалку:

1. "Не Переменная1 = Переменная2"
2. Переменная1 <> Переменная2
3. ...а мне побоку...
4. Условие = Не Переменная1 = Переменная2;
   Если (Условие) Тогда
5. ...Работать раб...

(48) а что, по новым правилам ПБУ, бюрократия == <>рократия? __

Я поставил себе 1с:AutoDesigner и не парюсь

1. не (неопределено = ложь)
2. неопределено <> ложь

одинаково...

а теперь так
1. не (СоставнойРеквизит = ложь)
2. СоставнойРеквизит <> ложь

будет разница в скорости...

(46) А чем это название переменной хуже других? ;)

(51) Так онож одни горячие кнопки эмулирует другими...

(53) Переменным надо давать говорящие имена (за исключением простых счетчиков или тривиальных случаев).

(54) альт и б == <
какие горячие кнопки?

(50) Пятнично )))

(42) А вот фиг знает. Это давалось как аксиома)

Конфигуратор и так не богат возможностями, так народ еще и про автозамену не знает...

(55) Типа ЗдесьЛежитСписокДокументовНаРеализациюКоторыйЯПолучилИзЗапросаВДругойПроцедуреПоУсловиямОтбораПользователяПупкинаИзложеннымВЗаявкеНомер12345?

(46) бюджет, бюллетень

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

(62) +100

(51) у него всё хорошо, кроме того, что когда он включен глючит множественное выделение с контролом, иногда альты залипают...
(54) зато там контрол-ку вызывает конструктор запроса в конфигураторе :)

(0) по стандартам 1с не рекомендуется вариант 1

(65) цитату, плиз

(0) Имхо, чем меньше "Не", тем читабельнее код, нужно стремиться минимизировать их количество в коде, в разумных пределах, конечно же. А вообще, гулусувалку бы прикрутила, штоле.

(62) А то - скроллить туда-сюда замучаешься ;)

Вариант:
Если Что-то = Ложь Тогда
Пишу:
Если НЕ Что-то Тогда
Во всех остальных случаях стараюсь писать:
Если Что-то1 <> Что-то2 Тогда

понимается лучше...

http://1c.chistov.pro/2013/09/83_15.html
Не все удобно. Вместо " Коллекции значений Всем известные ТЗ, СЗ и ХЗ."
По мне удобнее написать "новый" и из выпадающего списка уже выбрать: Соответствие, массив, ТаблицаЗначений и пр.

Все-таки адинэсники - не программисты :)

Конструкцию <> исторически не применяют в ПО, связанном с базами данных, так как следующий код вернет 2:

if (null != null)
  cout << 1
else
  cout << 2;

В то время как
if !(null == null)
  cout << 1
else
  cout << 2;

вернет более логичную 1

Врочем в 1С на это наплевали и там null = null.

(69) дайте ему печеньку, кто нибудь

(65) По любым стандартам предпочтительнее максимальное упрощение выражения.

(70) + Вместо "ИначеЕсли" я набираю "ие" и т.д.

(70) Так я только рад критике, добавим, исправим... Пишите!

Вот мои находки (не претендую на истину или авторство). Из часто используемого

пд    '00010101'
фд    Формат(<?>, "ДФ=dd.MM.yyyy")
н     Неопределено
л     Ложь
Ис    Истина
зз    ЗначениеЗаполнено(<?>)
ззс   ЗаполнитьЗначенияСвойств(<?>,);
пр    ПериодРегистрации


оф

Для Каждого ОформлениеСтроки Из ОформленияСтрок Цикл
    ДанныеСтроки = ОформлениеСтроки.ДанныеСтроки;
    <?>
КонецЦикла;


Дляч

Для ч = 1 По <?"Ограничение"> Цикл
    <?>
КонецЦикла;


Длят

Для каждого т Из <?"Коллекция"> Цикл
    <?>
КонецЦикла;


Новый

<?"Тип", ВыборВарианта, "Соответствие", "Новый Соответствие;", "Структура", "Новый Структура(<?>,)", "ТабличныйДокумент", "Новый ТабличныйДокумент", "СписокЗначений", "Новый СписокЗначений;", "ТаблицаЗначений", "Новый ТаблицаЗначений;", "Массив", "Новый Массив;"
"Шрифт", "Новый Шрифт(<?>, , , , , ); //    КОНСТРУКТОР Имя шрифта, Размер, Жирный, Наклонный, Подчеркнутый, Зачеркнутый">




Пользуйтесь кому лень )

(76) +


зуп

Запрос.УстановитьПараметр("<?"Параметр">", <?"Параметр">);


(71) логично

(76) чисто из любопытства, сокращая Истина, до Ис, куда вы тратите сэкономленные секунды?)

(79) Предполагаю для рассуждения смысла жизни :)

(76) а где эту настройку сделать?

(79) Я набираю ис получается Истина. И даже шифт не надо нажимать.

(81) Нажми сочетание Ctrl+Shift+T в конфигураторе.
+ в параметрах надо включить автозамену.

(82) хочу так же сделать ) а где это настроить?

(83) спасибо!

(69) напоминаю, что
Если Что-то = Ложь Тогда
корректно отработает в случае Что-то=Неопределено,а вот
Если НЕ Что-то Тогда
вылетит с ошибкой.

(85) Скачай готовый шаблон. Потом уже подправишь если надо будет.

Где-то читал, что в запросах "<>" может быть транслировано  в логическое "ИЛИ", а то уже может пролететь мимо индексов. За правдивость отвечать не берусь.

(87) + Можно отключить стандартный шаблон, а то путается под ногами, точнее руками...

(77) Есть "УП" = "УстановитьПараметр(");

(79) На ругань когда приходится на неподготовленном месте работать :)

(90) Одно другому не помешает.

Я фикси мне проще.

1) Теоретически оператор равенства и директива (Не =) должны работать быстрее, чем оператор неравенства (<>), поскольку при проверке на равенство значений ситуация различия их типов уже означает, что равенство не выполнено, в то время как при проверке на неравенство ситуация различия типов требует преобразования типов к идентичному, чтобы проверить неравенство при наиболее возможной ситуации равенства. Однако на практике техническая реализация оператора неравенства может быть разной, то есть программа при проверке на неравенство может на самом деле выполнять формальную проверку на равенство и возвращать обратный полученному результат. Поэтому в каждом частном случае быстродействие лучше определять замерами.

2) В среде 1С неявное преобразование типов может приводить к глюкам, потому предпочтительнее не провоцировать ситуации, где произойдёт такое автоматическое преобразование типов, в том числе в условиях директив.

3) В других средах разработки (не 1С) компилятор может не воспринимать сочетание "<>" как оператор неравенства, а считать это сочетанием математических операторов сравнения, применимых лишь для числовых типов (и это как раз правильно с чисто формальной точки зрения), и если вы привыкли везде использовать "<>", то придётся переучиваться.

Как уже говорили если один из параметров NULL с <> можно попасть. например (NULL<>1) - тут ложь, НЕ (NULL=1) - а вот тут уже истина.

(95) каким образом (NULL<>1) может вернуть ложь?

(96) Любое выражение с null в большинстве языков возвращает null, а null может быть неявно приведен к false.

(97) в 1совских запросах в общем то та же ситуация. Если ты делаешь к примеру в запросе условие "Регистратор.Контрагент<>&ВыбКонтрагент"
То ожидаешь что все регистраторы у которых контрагент не равен выбранному попадут в твою выборку. А не тут то было. регистраторы у которых вообще нет реквизита контрагент сюда не попадут. В то время как если сделать условие "НЕ Регистратор.Контрагент=&ВыбКонтрагент" это условие отработает уже корректно.

(96) это написано в стандарте на SQL
https://ru.wikipedia.org/wiki/NULL_(SQL)

(98) Когда я вижу в запросах Регистратор.Чтото - мне хочется убить автора запроса.

(100) И чего ты будешь делать если тебе надо контрагента из всех регистраторов регистра?

(101) Критерий отбора сделаю, или журнал, или регистр под эту задачу. Но никогда не буду делать запрос порождающий овер 256 соединений.

(102) Пусть это обработка которая запускается раз в месяц и соответственно работает ли она 10 секунд или 10 минут никого не интересует. И пусть ограничение в 256 таблиц не актуально, например регистраторов всего 20-30. Даже при таких условиях ты будешь вносить кучу изменений в конфигурации из-за каких то своих принципов?

(103) Обращение к регистратору в регистрах есть признак плохого проектирования регистра.

Голосовалку прикрути ))
Я использую <>, так проще код читать.

Развели тему на 100 постов.
Вот обработку за 3 минуты сделал:

http://hostingkartinok.com/show-image.php?id=430ef0efeb0ed69a89e074a4fc7d7d3c

Цикл на 1 000 000 сравнивает "не" и "<>"
Если 1<>1 Тогда    - 0,000003 секунд
Если не 1=1 Тогда - 0,000002 секунд

Не быстрее, но на 1 миллион, это вообще никак.

(104) Далеко не факт. При проектировании регистра невозможно предусмотреть все будущие задачи.

(106) Я в курсе, именно по этому у 1с периодически выходят новые редакции типовых. Переосмысленные, так сказать.

(105)
Извините, в цикл не попал.
Вот:

http://hostingkartinok.com/show-image.php?id=e5310711cd6823b920b84c78ce77d2f7

Если 1<>1 Тогда    2,437339 секунд
Если не 1=1 Тогда 2,310229 секунд

Разница на миллион доли секнуд

(6) Согласен)

(97) C/C++ явно к этим языкам не относится ;)

(100) А почему не автора регистра?

обычно в коде есть куда более стоящие вещи, чтобы их оптимизировать:) чем НЕ= и <>

(108) Тест неверный! Нужно мерить по очереди, а не в куче. Попробуй условия местами поменять, результат будет противоположный.

Итак, всем всем всем! Конструкция "<>" все же быстрее чем "НЕ"

Повторяя тест в (108), было проведено трехкратное измерение обоих условий, начиная со второго запуска цикла.
Получены следующие данные чистого времени выполнения конструкций:

Если НЕ 1=1 Тогда
0.748
0.755
0.757

Если 1<>1 Тогда
0.728
0.741
0.726

Итого, <> отрабатывает быстрее на несколько миллионных долей секунды.
Платформа 8.3.5, цикл выполнялся на стороне сервера.

(0)  Не Переменная1 = Переменная2 - это вынос мозга, по рукам за такое

(0) отличный вопрос! В системах двоичной логики - без разницы.
В системах троичной логики разница есть.

(0) вы это слышали там где рассказывалось про SQL. Ибо среда SQL использует троичную логику. Там есть true, false и unknown. В случае сравнения NULL с NULL возвращается не true как можно было бы ожидать, а unknown.

(94)+ Помимо чисто технических соображений есть ещё и факторы восприятия, о которых тут уже говорили (хотя и весьма субъективно).

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

В других же случаях сочетание "Альфа<>Омега" первым делом вызывает впечатление, что сравниваются числа. Затем, если имена переменных имеют явно нечисловое смысловое наполнение ("Контрагент<>НашаФирма"), следует вывод, что "это не числа", после чего следует узнавание самой комбинации "<>" ("это неравенство"), после чего следует конечный вывод ("контрагент - не наша фирма").
А при условии "Не Контрагент=НашаФирма", следуют лишь две мыслительных операции: "не выполнено условие..." и "не наша фирма".

Когда такие условия встречаются редко, трудности восприятия конструкции "<>" могут быть совсем незаметны, ведь всё происходит за доли секунды. Но когда в модуле множество всевозможных условий, когда условие неравенства повторяется многократно, чередуясь с другими, более сложными условиями, тогда заминки при встрече "<>" становятся куда ощутимее.
Я, например, больше десяти лет всегда писала "<>", даже ещё года полтора назад писала "<>". Теперь же всегда ставлю "Не =", в том числе когда свои же старые модули встречаю, переделываю на "Не =", ибо реально легче воспринимается.

(113) теперь сделайте тест для поля составного типа и утритесь

В типовых используют Не

(110) Ессно, в стандарте C++ нет NULL в смысле баз данных (null-pointer - это совсем другое). А что там в конкретной библиотечке нарисуют можно только гадать, поэтому только !(==)

(118) В чем проблема? Ну сделай и выложи результат сюда, куле)

В институте на первой лекции по программированию на языке фортран-76 наш Преподаватель целых 45 минут объяснял ветвления IF и логические операторы, так про "<>" было объяснено,  что это три оператора "<" "ИЛИ" ">", а про "НЕ" "РАВНО" - это два оператора. И еще много такого, чем пользуюсь до сих пор...
Так что у меня "НЕ =".

По итогам ветки теперь буду писать Если НЕ (а = 1) ТОгда...

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

(12) в языке 1с не так тупо воспринимается. <> это один символ, а не сумма двух.

(120) А в стандарте какого большинства языков он есть?