Здравствуйте, yenik, Вы писали:

Y>Мои коллеги считают, что if (!service.IsStarted) — это нечитабельно, восклицательный знак не видно красными глазками.
Гы. Тогда уж if (true == service.IsStarted) чтобы уж по всем канонам.

Сразу оговорюсь, что вопрос больше не про философию программирования, а про психологию программистов.

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

О каких мирах речь? Есть такая практика — стараться использовать тип bool с большим разбором. Например, если есть упрощённая ("динозавровая") модель сервиса (или запущен, или нет — 50/50, состояния "запускается" и "глушится" принципиально не учитываются), надо не bool isStarted, а расписывать поле состояний (Started, NotStarted) в енаме. Логика тут такая, что если мы берём bool, то просто приспосабливаем другое, нерелевантное поле состояний только потому, что у него то же число элементов (два), а это, как вы понимаете, зашквар. Конечно, если правильно сформулировать имя (isStarted), то острота проблемы снижается, но всё равно "как-то, доктор, неаккуратненько". Особенно неаккуратненько это выглядит при рассматривании вызова функции с десятью bool'ами.

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

Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.

Здравствуйте, Alekzander, Вы писали:

A>Мне лично nullable bool кажется опасной штукой, и я не поленюсь расписать .has_value() и .value() (даже не operator *). (Речь в данном случае про std::optional).

Вот опять началось. Кажется/не кажется. Всё зависит. Если надо, то пусть будет nullable. Не вижу особых проблем. Не удобно — да. Прям вот опасно — да с чего?

A>Как узнаю, что это оно — да просто таких отважных программистов, которые не боятся nullable bool, давно не попадалось. Всех знакомых сивок уже укатали крутые горки.

Я тебя умоляю... Вы в реальном мире живёте или где? Обычная ситуация — дремучая база данных с NULL BIT полями. Генерируем модель данных — получаем кучу bool?.

Здравствуйте, Alekzander, Вы писали:

A>Я считал (и считаю) это экстремизмом, и эта та причина, по которой я не люблю современную культуру C++

Зря ты сразу не упомянул C++, а из контекста не только стартового топика, но и всего треда это не понятно. Так бы я не стал встревать в обсуждение этого древнего овна. Тем более обсуждать "культуру" C++. Там же одно безкультурье, начиная со стандарта

Ну, скажем, изначально было "if (a == 1)", потом сделали булевую переменную, а единицы поменяли на true (типа, так быстрее).

Ещё "а == true" заметнее, чем "а". Компилятору/интерпретатору зрительная заметность не важна, но человек, который будет читать код, увидит, что тут не просто какое-то мелкое "а", но целое "а == true", а значит, что это очень-очень важно, чтобы было именно true.

Y>Мои коллеги считают, что if (!service.IsStarted) — это нечитабельно, восклицательный знак не видно красными глазками.
Вот так виднее: if (!(service.IsStarted))
Но если нужно, чтобы совсем виднее, то так:

bool serviceNotStarted = !service.IsStarted;
if (serviceNotStarted) { /*  */ }

Здравствуйте, Alekzander, Вы писали:
A>Это хуже йодинга: смысл перестановка меняет незначительно лишь, а инверсия страшная тут.
Смысл меняется, и очень-очень сильно. true обычно равно 0xFFFFFFFF.
При этом if(a) компилируется/интерпретируется как if(a!=0), подразумевая любое ненулевое значение.
В итоге, если в a попадает 42, то if(a == true) пройдёт мимо, а if(a != false) зайдёт внутрь. Как и if(a).
Так что, возможно пишет if(a == true) вовсе не идиот.
Может быть, a имеет тип "недоперечисления", которое организовано так, что -1 = started; 0 = stopped; 1 = starting; 2 = stopping; 16 = error. Для совместимости с совсем древним кодом, который написан для времён с двумя статусами сервиса, которые он проверял через if(!service->status).
А теперь нам нужен код, который убеждается, что сервис именно что запущен.

A>Если тип не bool, они в таких случаях пишут каст плюс == true.
Даже если тип bool, не всегда он сформирован честным образом из констант true, false, и булевых операций. Даже в дотнете я налетал (правда, из-за бага в моём же unsafe коде) на то, что булевая логика на SIMD дала не true, а non-false результат. В итоге, код с if(a) прекрасно работал, а вот тесты, которые сравнивали вычисленный массив булеанов с референс-значениями, фейлились.

A>Боюсь, не совсем понимаю. service.IsStarted это почти наверняка функция (аксессор). И?
Всё зависит от системы типов в языке.
Например, if(service.IsStarted) внезапно убеждается, что адрес этой функции ненулевой. И если ваш язык — не typescript, то не всякий компилятор будет вам намекать на отсутствие скобок.
А вот if(service.IsStarted == true) уже имеет некоторые шансы нарваться на no operator== defined for the arguments of type 'bool (*check)()' and 'bool'.
С другой стороны, это недостаточно каргокультно.
По классике, нужно писать вот так:

if(true == service.IsStarted())

По-мне этот вопрос выеденного яйца не стоит.

Плохо, когда пишут if (size), к примеру, используя неявное приведение int к bool. Это прям очень плохо, я считаю.

Допустимо, когда пишут if (obj_ptr), используя неявное приведение указателя к bool. Я так не пишу, но беды в этом не вижу.

Писать if (isStarted) либо же if (isStarted == true) — вообще разницы не вижу. Я бы написал первый вариант, но второй так же прекрасно читается. Допускаю, что кому-то он читается лучше.

Вот и весь сказ. Если есть твёрдый кодовый стиль, придерживайтесь его. Если нет — пишите как хотите с учётом изложенного выше.

Городить enum-ы на ровном месте? Не знаю. Я обычно этого не делаю. Но если очень хочется — да ради бога...

Здравствуйте, Alekzander, Вы писали:

A>>>Когда я давным-давно впервые увидел в коде сабж, то решил, что автор издевается (особенно без йода-сравнений). Но так действительно пишут, и нередко.
K>>это не про nullable?
A>Нет, и не про operator bool.

А как ты узнаешь глядя на код, что это не оно? Наверняка, первое, что подумаешь — "Ааааа! Опять очередной говнокодер-извращенец!".
Или тут же пойдёшь определение переменной проверять?

Мне лично такая хрень вообще по барабану. В зависимости от обстоятельств могу написать и так и так. Например:

if (a == true) ... // a is bool
if (b == true) ... // b is bool?

вместо

if (a) ... // a is bool
if (b == true) ... // b is bool?

А если кто-то решит такое покритиковать, то минимум заслужит покручивание пальцем у виска.

Здравствуйте, Sinclair, Вы писали:

S>По классике, нужно писать вот так:
S>

S>if(true == service.IsStarted())
S>

А современный C# подарил нам прекрасный способ

if (service.IsStarted is true) //хотя наверное service.Started выглядело бы красивее

Здравствуйте, Alekzander, Вы писали:

A>Сразу оговорюсь, что вопрос больше не про философию программирования, а про психологию программистов.
if (a===true)

A>Когда я давным-давно впервые увидел в коде сабж, то решил, что автор издевается (особенно без йода-сравнений). Но так действительно пишут, и нередко. В настоящий момент я думаю, что это глупый способ взять худшее из обоих миров.
тогда лучше писать
if (a!=false)

A>О каких мирах речь? Есть такая практика — стараться использовать тип bool с большим разбором.
А кто сказал что а имеет тип bool ?

A>Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.
А если service.IsStarted это функция или перечисление. А так компилятор уматерит если что. А вообще это просто шаблонное поведение если в переменной такое значение то делаем то-то. А оптимизировать это дополнительное действие — лень. Более того тот кто писал вообще может быть с булевой алгеброй не знаком, и это ему совершенно не мешает.

Здравствуйте, kov_serg, Вы писали:

A>>Сразу оговорюсь, что вопрос больше не про философию программирования, а про психологию программистов.
_>if (a===true)

Надо было уточнить, что речь про ЯП без === (я так понимаю, === имеет смысл только для нестрого-динамической типизации).

A>>Когда я давным-давно впервые увидел в коде сабж, то решил, что автор издевается (особенно без йода-сравнений). Но так действительно пишут, и нередко. В настоящий момент я думаю, что это глупый способ взять худшее из обоих миров.
_>тогда лучше писать
_>if (a!=false)

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

_>А кто сказал что а имеет тип bool ?

Если тип не bool, они в таких случаях пишут каст плюс == true.

A>>Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.
_>А если service.IsStarted это функция или перечисление. А так компилятор уматерит если что. А вообще это просто шаблонное поведение если в переменной такое значение то делаем то-то. А оптимизировать это дополнительное действие — лень. Более того тот кто писал вообще может быть с булевой алгеброй не знаком, и это ему совершенно не мешает.

Боюсь, не совсем понимаю. service.IsStarted это почти наверняка функция (аксессор). И?

Здравствуйте, Alekzander, Вы писали:

A>Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.

Нет, просто считают, что так более понятно.
assert(something)
assert(!something)
assert(something == true)
assert(something == false)

Здравствуйте, scf, Вы писали:

A>>Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.

scf>Нет, просто считают, что так более понятно.
scf>assert(something)
scf>assert(!something)
scf>assert(something == true)
scf>assert(something == false)

Раз ты не привёл пример something, пусть мы ассертируем запущенность сервиса, о которой речь шла выше.

assert(service.IsStarted) это лаконично.
assert(service.State == ServiceState.Started) это понятно. (Понятность проявляется не в assert'е, хотя это кому как, а когда мы позже передаём аргумент ServiceState.Started в какую-нибудь функцию вместо true).
assert(service.IsStarted == true) это ни туда ни сюда.

A>Когда я давным-давно впервые увидел в коде сабж, то решил, что автор издевается (особенно без йода-сравнений). Но так действительно пишут, и нередко.

это не про nullable?

Здравствуйте, kov_serg, Вы писали:

A>>Сразу оговорюсь, что вопрос больше не про философию программирования, а про психологию программистов.
_>if (a===true)

Со второго раза я понял. Нахватались у динамиков, ты про это, да?

Здравствуйте, koenig, Вы писали:

A>>Когда я давным-давно впервые увидел в коде сабж, то решил, что автор издевается (особенно без йода-сравнений). Но так действительно пишут, и нередко.

K>это не про nullable?

Нет, и не про operator bool.

Мои коллеги считают, что if (!service.IsStarted) — это нечитабельно, восклицательный знак не видно красными глазками.
Поэтому надо писать так: if (service.IsStarted == false).
А для консистентности также if (service.IsStarted == true)
И они реально так пишут. Я вначале удивлялся на код-ревью, но потом привык.
Мопед не мой, если что, отстаивать эту точку зрения не буду.

Здравствуйте, yenik, Вы писали:

Y>Мои коллеги считают, что if (!service.IsStarted) — это нечитабельно, восклицательный знак не видно красными глазками.
Y>Поэтому надо писать так: if (service.IsStarted == false).

эта рекомендация точно из какой-то книги. Возможно Фаулер "Рефакторинг". То есть коллеги не от больной фантазии это придумали. Да и отчасти согласиться можно — знак ! легко можно пропустить.

Здравствуйте, yenik, Вы писали:

Y>Мои коллеги считают, что if (!service.IsStarted) — это нечитабельно, восклицательный знак не видно красными глазками.
Y>Поэтому надо писать так: if (service.IsStarted == false).

По-моему, это свидетельствует в пользу моей гипотезы.

A>Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.
Эт ты глубоко копнул.
Все проще — у меня начинающие так пытаются писать, пока я им по рукам не дам.
После пи*лей — сразу как-то все понимают и начинают писать нормально

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Alekzander, Вы писали:
A>>Это хуже йодинга: смысл перестановка меняет незначительно лишь, а инверсия страшная тут.
S>Смысл меняется, и очень-очень сильно. true обычно равно 0xFFFFFFFF.

Это в каких языках?

S>Может быть, a имеет тип "недоперечисления", которое организовано так, что -1 = started; 0 = stopped; 1 = starting; 2 = stopping; 16 = error. Для совместимости с совсем древним кодом, который написан для времён с двумя статусами сервиса, которые он проверял через if(!service->status).
S>А теперь нам нужен код, который убеждается, что сервис именно что запущен.

if (service == STARTED)

А вот использовать тот факт, что битовое представление true совпало с битовм представлением STARTED — это говнокод

Разница между if (a == true) и if (a) в том, что в первом случае проверяется точно ли а равна константе true а во втором неравенство а нулю. Некоторым это важно. Скажем в C++ bool это тип и ему можно просвоить в коде только true или false a в C bool это байт (иногда BOOL) Tут можно присваивать вообще что угодно, компилятору похрен. Да, кстати, может этой переменной вообще никогда ничего не приваивали и значение ее — хрен знает (что в пределах байта). Тут даже строгая типизация C++ не поможет.

Я вообще у шибко строгих принято даже не if (a == true) а if (true == a).

Здравствуйте, Sinclair, Вы писали:

A>>Это хуже йодинга: смысл перестановка меняет незначительно лишь, а инверсия страшная тут.
S>Смысл меняется, и очень-очень сильно. true обычно равно 0xFFFFFFFF.
S>При этом if(a) компилируется/интерпретируется как if(a!=0), подразумевая любое ненулевое значение.
S>В итоге, если в a попадает 42, то if(a == true) пройдёт мимо, а if(a != false) зайдёт внутрь. Как и if(a).
S>Так что, возможно пишет if(a == true) вовсе не идиот.
S>Может быть, a имеет тип "недоперечисления", которое организовано так, что -1 = started; 0 = stopped; 1 = starting; 2 = stopping; 16 = error. Для совместимости с совсем древним кодом, который написан для времён с двумя статусами сервиса, которые он проверял через if(!service->status).
S>А теперь нам нужен код, который убеждается, что сервис именно что запущен.

Я понял kov_serg'а так, что он предлагает в качестве альтернативы йода-сравнению (if (true == a)) инверсию (if (a != false)). Ведь при инверсии тоже нельзя нечаянно присвоить значение, перепутав = и == (помешает !), зато не придётся переставлять переменную в конец. Может, конечно, понял неправильно.

На это я ему возразил, что от перестановки при йода-сравнении (if (a == true) → if (true == a)) смысл меняется незначительно (читается почти так же, выполняется одинаково), а вот предложенная инверсия — вещь страшная. Потому, что читается сильно иначе. После этого меня уже не волнует, насколько одинаково выполняется. Что показывает нам, как много проблем можно автоматически избежать, просто стремясь к выразительности.

A>>Если тип не bool, они в таких случаях пишут каст плюс == true.
S>Даже если тип bool, не всегда он сформирован честным образом из констант true, false, и булевых операций. Даже в дотнете я налетал (правда, из-за бага в моём же unsafe коде) на то, что булевая логика на SIMD дала не true, а non-false результат. В итоге, код с if(a) прекрасно работал, а вот тесты, которые сравнивали вычисленный массив булеанов с референс-значениями, фейлились.

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

Но любители буля скажут, наверно, что те, кто не обеспечил строгий true и false, нарушили контракт. И тоже будут по-своему правы.

A>>Боюсь, не совсем понимаю. service.IsStarted это почти наверняка функция (аксессор). И?
S>Всё зависит от системы типов в языке.
S>Например, if(service.IsStarted) внезапно убеждается, что адрес этой функции ненулевой. И если ваш язык — не typescript, то не всякий компилятор будет вам намекать на отсутствие скобок.
S>А вот if(service.IsStarted == true) уже имеет некоторые шансы нарваться на no operator== defined for the arguments of type 'bool (*check)()' and 'bool'.
S>С другой стороны, это недостаточно каргокультно.
S>По классике, нужно писать вот так:
S>

S>if(true == service.IsStarted())
S>

Теперь понял. Ну, смотря как делать свойства в языке-принимающем-адрес-за-true. Если их делать аналогично шарповским, через __declspec (поддерживается в clang с опцией компилятора -fdeclspec и MSVC), то перепутать нельзя, не скомпилируется:

https://gcc.godbolt.org/z/fdW74ocfG

Обе части 1 и 2 должны соответствовать.

(А по стандарту их надо делать через такую задницу, что лучше вообще не делать).

Глобальная же функция всего лишь даёт ворнинг. Что неприятно, да. То есть, как подстраховка от (забыли скобки) x (проигнорировали ворнинг) x (глобальная функция) x (сигнатура: возвращает bool, не имеет параметров) x (в норме всегда возвращает true, и не ловится при первом же запуске) добавление == true действительно помогает

Здравствуйте, LaptevVV, Вы писали:

A>>Так вот, у меня появилась гипотеза, что те, кто пишет if (service.IsStarted == true), просто слышали звон. Останавливаются на половине, пытаются изображать строгость, при этом не расписывая состояния для каждого кейса.
LVV>Эт ты глубоко копнул.
LVV>Все проще — у меня начинающие так пытаются писать, пока я им по рукам не дам.
LVV>После пи*лей — сразу как-то все понимают и начинают писать нормально

Пи*лей ведь можно не только дать, но и получить ))

Я имею в виду, что они скажут: "Это у нас нормально". И придётся копать и аргументировать.

LVV>>Все проще — у меня начинающие так пытаются писать, пока я им по рукам не дам.
LVV>>После пи*лей — сразу как-то все понимают и начинают писать нормально
A>Пи*лей ведь можно не только дать, но и получить ))
Ну, не от студентов же
A>Я имею в виду, что они скажут: "Это у нас нормально". И придётся копать и аргументировать.
Студенты не скажут.
Тут же как в шахматах.
Начинающих учат: конь на краю доски — очень плохо.
И аргументируют вполне разумно — ходов мало, стоит как пень, ничего не делает
Но гроссмейстеры играют на край конем, когда надо.

Поэтому мой ответ студентам: сначала стань гроссмейстером, а потом играй конем на край.
Когда это будет полезно.

В конторе это может быть было сделано когда-то таким же джуном.
Или для каких-то джунов. Это надо спрашивать у них.


Еще очень часто встречается у начинающих:

if(логическое выражение) return true; else return false;

Здравствуйте, LaptevVV, Вы писали:

LVV>Начинающих учат: конь на краю доски — очень плохо.
LVV>И аргументируют вполне разумно — ходов мало, стоит как пень, ничего не делает

Ну вот видишь, аргументируют же. А не говорят: "Я гроссмейстер — ты дурак".

LVV>Студенты не скажут.

Это смотря какой студент попадётся.

У меня в третьем классе был физрук, телосложением напоминавший первую советскую атомную бомбу РДС-1. Как-то он начал докапываться до чистоты прыжка через снаряд, на что я ему сразу сказал: "Так покажите, как надо". Если бы мне на вопрос, почему надо (или не надо) писать таким-то образом, ответили: "Потому что потому", я бы для начала поинтересовался, где работал гроссмейстер и какими проектами он славен. Не для того, чтобы ему поверить на слово (на слово верить нельзя никому), а просто чтобы понять, надо ли вообще принимать его во внимание.

Кстати, именно поэтому я программированию пошёл учиться на предприятие, где пилили кем-то реально используемые системы, а в универ только в сессии приходил.

Здравствуйте, IT, Вы писали:

A>>>>Когда я давным-давно впервые увидел в коде сабж, то решил, что автор издевается (особенно без йода-сравнений). Но так действительно пишут, и нередко.
K>>>это не про nullable?
A>>Нет, и не про operator bool.

IT>А как ты узнаешь глядя на код, что это не оно?
IT>Или тут же пойдёшь определение переменной проверять?

IT>Мне лично такая хрень вообще по барабану. В зависимости от обстоятельств могу написать и так и так. Например:

Мне лично nullable bool кажется опасной штукой, и я не поленюсь расписать .has_value() и .value() (даже не operator *). (Речь в данном случае про std::optional).

Как узнаю, что это оно — да просто таких отважных программистов, которые не боятся nullable bool, давно не попадалось. Всех знакомых сивок уже укатали крутые горки.

Здравствуйте, IT, Вы писали:

A>>Мне лично nullable bool кажется опасной штукой, и я не поленюсь расписать .has_value() и .value() (даже не operator *). (Речь в данном случае про std::optional).

IT>Вот опять началось. Кажется/не кажется.

Ты написал: "Мне лично", и я в тон ответил: "Мне лично". Если и началось, то не с меня.

A>>Как узнаю, что это оно — да просто таких отважных программистов, которые не боятся nullable bool, давно не попадалось. Всех знакомых сивок уже укатали крутые горки.

IT>Я тебя умоляю... Вы в реальном мире живёте или где? Обычная ситуация — дремучая база данных с NULL BIT полями. Генерируем модель данных — получаем кучу bool?.

Меня бесполезно умолять, реальный мир от этого не изменится. Я много где работал, и везде, абсолютно везде, где люди использовали плюсы и до появления std::optional (C++17) писали свой nullable из говна и палок, они НИКОГДА не делали ни operator T, ни сравнения. Чистые .has_value()/.value().

Я считал (и считаю) это экстремизмом, и эта та причина, по которой я не люблю современную культуру C++ (даже странно, что сравнения с T там всё-таки реализовали), но даже я бы никогда не использовал == true, чтобы вытаскивать bool из nullable. Ни на одном языке.

Но я тебя услышал. В смысле, гипотезу о том, что если писать == true, это позволит универсально обходиться и с булями и с nullable, и именно поэтому люди так и пишут.

Здравствуйте, IT, Вы писали:

A>>Я считал (и считаю) это экстремизмом, и эта та причина, по которой я не люблю современную культуру C++

IT>Зря ты сразу не упомянул C++, а из контекста не только стартового топика, но и всего треда это не понятно. Так бы я не стал встревать в обсуждение этого древнего овна. Тем более обсуждать "культуру" C++. Там же одно безкультурье, начиная со стандарта

Потому что тред не про C++.

	Исключительно для тех, кому интересно моё скромное мнение
	Я бы и на шарпе написал a.HasValue && a.Value. Дело даже не в том, что их можно перепутать, а в том, что так нагляднее. Речь не про автосгенерённый по базе код, а про обычные алгоритмы.