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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Здравствуйте, 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 выглядело бы красивее

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

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

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

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

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

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

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

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

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

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

Я тебя умоляю... Вы в реальном мире живёте или где? Обычная ситуация — дремучая база данных с NULL BIT полями. Генерируем модель данных — получаем кучу 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, и именно поэтому люди так и пишут.

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

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

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

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

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

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

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

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

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

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

Предположим, Земля круглая.
Предположим, Земля круглая — это верно.

Первое в разы лучше.

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

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

На java я всегда писал так:
if (!service.IsStarted) или так if (service.IsStarted)

на C#
if (service.IsStarted == false) и так if (service.IsStarted == true) и обычно такой вариант встречаю в коде у других, хотя по мне первый вариант лучше.

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


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

Я тут увидел старую тему и вспомнил еще один конченый случай. Когда у результата функции куча состояний, и ноль это успех, а все остальное это разные коды ошибок.
И чтобы проверить успешность, то казалось бы для проверки ошибочного случая логично писать

#define SUCCESS 0
if (service.started != SUCCESS) {
  // handle error
}

Но нет блин некоторые кодеры сокращают буквы и пишут так:

if (service.started) {
  // handle error
}

А я читаю и не пойму: если сервис стартанул то какая нахрен ошибка?!
Я не первый день на крестах пишу, я в курсе что ноль это фолс, но самих-то не корежит при виде такого условия?

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

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

Особенно неаккуратненько это выглядит, когда вдруг появляется третье состояние.

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

M>Но если нужно, чтобы совсем виднее, то так:
M>

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

Тогда уж лучше так:

bool serviceNotStarted;

if (!service.IsStarted) {
    serviceNotStarted = true;
} else if (service.IsStarted) {
    serviceNotStarted = false;
} else {
    panic();
}

assert(serviceNotStarted == !service.IsStarted);

Так уж точно все поймут.

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

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

Кем-то реально используемые системы иногда невероятно плохо написаны.

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

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

Это чтобы breakpoint ставить.

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

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

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

O>Это чтобы breakpoint ставить.
Ну, мои на таком уровне пишут, что не о bp думают, а просто не думают... )

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

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

if (a==true) {}// нагляднее чем
if (a.HasValue && a.Value){} //тут намного больше визуального шума