Сделайте большую сделку из == правда?

Мой коллега постоянно пишет:

if (someBool == true)

Это доводит меня до стены! Должен ли я сделать большое дело или просто бросить его?

Это всего лишь избыточный код, а не жизнь или смерть. Тем не мение....

Если это происходит много, это может быть проблемой с тем someBool, как называется. Хорошее имя может иметь большое значение для устранения необходимости==true

if(IsSomeCondition)

или же

if(hasCondition)

или же

if(somethingExists)

например.

Когда я вижу someBool == true, я не могу не чувствовать, что программист не усвоил идею оценки , что является довольно существенным недостатком.

Тем не менее, моя точка зрения искажена, потому что я провел несколько лет в колледже, обучая программированию детей, которые часто писали такие выражения, потому что они по-настоящему не освоили умственное упражнение по оценке выражения. Как только они ухватились за концепцию, избыточность стала очевидной.

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

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

В качестве альтернативы вы можете попробовать этот подход:
Вы: Можете ли вы начать использовать следующее соглашение кода для оценки логических значений?

if (someBool==true)&&(true==true) {}

ИМ: Зачем нам это делать? Вторая половина этого утверждения является избыточной, она всегда будет иметь значение true.

Вы: Джорджем, вы правы. Дурак я. Тогда давайте просто перейдем к версии без избыточности. Как насчет?

if (someBool) {}

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

Вы должны определенно остановить эту вредную привычку. Осторожно ...

Легко забыть написать двойные знаки равенства, превращая код в:

if (someBool = true)

Например, в C # это будет выдавать только предупреждение, а не ошибку. Поэтому, если вы не воспримете предупреждения как ошибки, код будет выполняться, установите для переменной значение true и всегда вводите условие.

Я согласен с вами, но я собираюсь сыграть адвоката дьявола здесь:

В зависимости от языка и имени переменной подходит x == true:

Рассмотрим следующую ситуацию в языке со статической типизацией и приведением типов для целочисленных типов:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Кто-то, читающий этот раздел кода, может не сразу понять, что actionsAllowed является булевой переменной - это также может быть целое число, представляющее количество разрешенных действий. Таким образом, добавив == true, становится ясно, что x является логическим значением, а не целым числом, приведенным к логическому:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

А как насчет бул?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

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

При этом я не вижу проблем с добавлением == trueк условному выражению. На самом деле, я имею обыкновение использовать == falseв отличие от ведущего восклицательного знака при тестировании на негативные условия. Я думаю, что это более читабельно.

Если существует установленное соглашение, я говорю: следуйте ему, если нет причин для изменения. Тем не менее, это не стоит поднимать вонючий вопрос.

Ack. Я тот парень. Стыд, позор. Это то, как я учился, и то, как я «автоформатировал» в своей голове. Единственный раз, когда я использую предпочтительный синтаксис Джоэла, это когда переменная bool имеет префикс глагола типа «есть». Мне нужен глагол, будь то «есть», «может», «сделал», или же мне нужен ==, чтобы обеспечить глагол «равно». Я мог бы никогда не сломать эту привычку, поэтому я пойму, если вы не скажете «привет» мне на улице.

напомни мне о "булевом коде безумия", вот так

if(someBool == true)
   otherBool = false;
else
   otherBool = true

Вместо:

 otherBool = !someBool

Лично мне сильно не нравится, когда я говорю «нет» в языках, основанных на Си. Этот маленький восклицательный знак слишком легко упустить из виду.

Поэтому я выписываю это полностью:

if (someCondition == false) {

Прочитав некоторое время, я тоже хочу симметрию с

if (someCondition == true) {

Так что считайте это артефактом использования C !вместо not.

Это зависит от языка, но обычно это плохая идея ...

В Си никогда не делай этого. Слишком легко найти ситуацию, когда проверяемое вами значение не является ложным (ненулевым), но также не равно единственному значению, определенному как «истина».

В Ruby, делайте это только в том случае, если вы абсолютно уверены, что хотите потерпеть неудачу во всем, кроме Boolean true.

В C ++ и других статических языках с типом bool он избыточен и может привести к ошибкам программирования при неправильном вводе =вместо ==или ошибкам продвижения, как указано в комментариях.

Ты думаешь это плохо? Как насчет:

if(someCondition) {
  return true;
} else {
  return false;
}

я предпочитаю

if (bVal)

или же

if (!bVal)

тоже, но я боюсь, что поднятие этого вопроса разозлит людей, поэтому я советую забыть об этом. Сожалею!

Вы должны сказать ему, что он делает это неправильно.

его

if (true == someBool) {

}

если он когда-нибудь забудет = у него большие проблемы с его стилем письма.

Как насчет

if (x == "true")

ПОЧЕМУ ЭТО СТРОКА ?!

На самом деле, если он может быть обнуляемым, необходимо проверить x == true. :)

Я пишу такой код!

Вот почему:

«if bla == true» читается как предложение, а «if bla» - не во многих случаях. Это просто звучит неправильно, когда ЧИТАЕТ реальный код.

Также компилятор предупреждает о присваиваниях в блоках if, поэтому при использовании == true нет никакой опасности. (путая это с =)

Также парни, которые не пишут "== true", используют это "! ()" Для "== false"? Я нахожу это действительно безобразным. И если вы используете «== false», то очень просто использовать «== true» вместо двух разных способов проверки истины.

Помните, что вы работаете как часть команды, поэтому вам нужно решить все это вместе. «Приятно играть с другими» остается важной чертой личности даже после начальной школы :)

Обычно пропускает '== true', но вряд ли стоит даже минуту, чтобы обсудить его, если вы не включите его в стандарты кодирования вашей команды.

Хотя я согласен как разработчик C #, я не могу сказать, что это всегда так. Например, в Javascript === будет выполнять слияние типов. Итак, предполагая, что var x = 3, тогда:

if(x) --> true

пока

if (x === true) --> false

Я думаю, это отличается от ==, поскольку даже в JS я бы не использовал if (x == true), а просто подумал.

Этот вид затрагивает другой момент, который возник в моем офисе:

bool b = false;

В C #, bool b; было бы достаточно и инициировало бы b в ложь . Тем не менее, более четко написать вышеприведенную строку и в любом случае должен быть разорван компилятором во время оптимизации.

Поэтому я думаю, что моя точка зрения состоит в том, что не всегда так очевидно, что является и не является хорошей практикой, и многое из этого сводится к предпочтениям, а также к особенностям / причудам языка.

Ах да, но что, если переменная может быть обнуляемой? (BOOL?)

Некоторые языки (C #) потребуют и приведут или сравнят с 'true'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

Молодые знают правила, а старые знают исключения;)

В последнем C#случае, если вы имеете дело с null-able bool, то вам необходимо:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Если tristate не является проблемой, то обычно не должно быть причины сравнивать что-либо с true/ True. Тем не менее, в Pythonнекоторых других языках, таких как C/C++вы, вы можете выполнять выражения, ifотличные от bool. Эти языки имеют уникальные правила для интерпретации целых чисел, указателей, списков и т. Д. Как истинных или ложных. Иногда ты этого не хочешь. Например, в этом фрагменте Python:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Здесь zдолжно быть True, но z2должно быть False. Теперь Clojureязык подходит к этому еще одним способом - там andфункция не обязательно оценивает a bool, но ifможет справиться с этим.

Независимо от языка, каждый раз, когда вы сравниваете что-то с Trueили False, это, вероятно, стоит комментировать.

Такое кодирование и раньше бы меня терло. Хотя ваш пример идентификатора называется «someBool», использование этого стиля кодирования непреднамеренно для переменной, которая не гарантированно является логическим, может иметь непреднамеренное поведение. Если значение «someBool» не совсем «истина» или «ложь», результат будет ложным.

В прошлом году я столкнулся с очень тонкой ошибкой, вызванной таким стилем кодирования, который трудно было идентифицировать, потому что глаза закрывают глаза на такие конструкции. Вы подумаете: «Как это может быть неправильно?» То же самое относится и к таким понятным выражениям, как «(var)» или «(! Var)», что вы читаете или кодируете их, не проверяя их поведение.

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

1. Все выражения должны быть заключены в скобки в соответствии с их намерением.
2. Все булевы тесты должны быть выражены отрицательно, например «suchBool! = False».

Очистив код, не соответствующий новому стилю, я выявил и исправил еще несколько примеров таких тонких ошибок.

Пришлось все время использовать это в ActionScript 2 (по общему признанию, теперь мертвый язык), потому что:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Так что почти всегда лучше быть конкретным.

Я согласен. Это избыточная конструкция, особенно в строго типизированных языках.

Чтобы добавить еще одно неправильное использование логических выражений, я встречал такую ​​конструкцию несколько раз в Javascript (особенно в некоторых спагетти-подобных функциях монстров, как в 100+ строках):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Кажется, что из-за отсутствия строгого определения типа в этом языке, некоторые программисты предпочитают не возиться со false|undefinedзначениями.

У меня есть коллега, у которого будет такой код:

if(something == true)

И затем, для какого-то теста / отладки, он захочет не вызывать этот блок, поэтому он изменит его на:

if(something == true && false)

И тогда иногда он изменит это на:

if(false)

Хуже всего то, что этот тип отладки иногда теряет меня и очень плох для чтения другими разработчиками!

Я бы сказал, что последовательность в корне кодов. Таким образом, вы должны использовать стиль, который в основном используется в вашей организации. Постарайтесь сделать ваш любимый стиль частью официального руководства по кодированию. Если это уже указано в руководстве, просто следуйте ему.

(Это сказанное, это также действительно раздражало бы меня - но вероятно недостаточно для того, чтобы сделать из этого большое дело).

Я предпочитаю не ставить дополнительные == true, но иногда я случайно включаю их и не замечаю. Человек, возможно, не заметил и случайно разместил их. Я перечитываю свой код и иногда замечаю, что я добавил лишний == true, поэтому я удаляю это == true. Иногда я этого не замечаю и с радостью приветствую того, что кто-то сказал мне, что я разместил это излишне.

как насчет:

int j = 1;
for (int i=1; i>=j; i++) ...

Да, я видел это.