Зробити велику справу з == true?

Є мій колега, який постійно пише:

if (someBool == true)

Це підводить мене до стіни! Потрібно чимось зробити це чи просто відкинути його?

Це лише зайвий код, а не життя чи смерть. Однак….

Якщо це відбувається багато, це може бути проблемою з тим, як someBoolйого називають. Добре ім'я може пройти довгий шлях до усунення потреби в цьому==true

if(IsSomeCondition)

або

if(hasCondition)

або

if(somethingExists)

наприклад.

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

Однак моя думка перекошена, тому що я проводив кілька літ у коледжі, навчаючи програмуванню дітям, які часто писали такі вирази, тому що вони справді не освоїли розумову вправу оцінювати вираз. Після того, як вони ринули концепцію, надмірність стала очевидною.

Для грамотного професійного програміста це, мабуть, не так. Це, мабуть, лише шкідлива звичка, яку вони розвинули в перші дні програмування і ніколи не похитнулися. Але це все одно мене трохи налякало б, якби це було першим, що я бачив когось робити в інтерв'ю.

Це і мене зводить з розуму, але я б сказав, що згадайте надмірність їм конструктивно, а потім відмовитись, навіть якщо вони не згідні.

Як варіант, ви можете спробувати такий підхід:
Ви: Чи можете ви почати використовувати наступну конвенцію коду для оцінки булевих?

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

Їх: Чому ми це зробимо? Друга половина цього твердження є зайвою, вона завжди оцінюватиметься правдою.

Ви: Джордж, ви праві. Дурний мене. Давайте просто підемо з версією без всякої надмірності тоді. Як щодо?

if (someBool) {}

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

Ви обов'язково повинні припинити цю шкідливу звичку. Акуратно ...

Не забути написати подвійні знаки рівності, перетворивши код на:

if (someBool = true)

Наприклад, у C # це створюватиме лише попередження, а не помилку. Тож якщо ви не ставитесь до попереджень як помилок, код буде працювати, встановіть змінну на істинне та завжди введіть умову.

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

Залежно від мови та назви змінної, 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на відміну від провідного оклику при тестуванні на негативні умови. Я думаю, що це читабельніше.

Якщо існує конвенція, я кажу, дотримуйтесь її, якщо немає підстав для змін. Однак не варто насправді викликати велику смердію.

Ак. Я той хлопець. Сором, ганьба. Це я дізнався, і як я "автоформатую" в голові. Єдиний раз, коли я використовую вподобаний синтаксис Джоеля, - коли змінна bool має префікс дієслова типу "є". Мені потрібне дієслово, будь то "є", "може", "зробив", інакше мені потрібно == надати дієслово "дорівнює". Я ніколи не можу порушити цю звичку, тому зрозумію, якщо ти не скажеш "привіт" мені на вулиці.

нагадуйте про "булевий код божевілля", подібний до цих

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

Замість:

 otherBool = !someBool

Особисто мені категорично не подобається спосіб сказати "не" мовами, що базуються на С. Цей маленький знак оклику занадто легко не помітити.

Тому я виписую його повністю:

if (someCondition == false) {

Прочитавши це деякий час, я теж хочу симетрії

if (someCondition == true) {

Тому вважайте це артефактом С, який використовує !замість not.

Це залежить від мови, але зазвичай це погана ідея ...

У С ніколи цього не робіть. Занадто просто знайти ситуацію, коли значення, яке ви тестуєте, не є хибним (не нульовим), але також не дорівнює єдиному значенню, визначеному як "справжнє".

У Ruby зробіть це лише в тому випадку, якщо ви абсолютно впевнені, що хочете зазнати невдач у всьому, крім булевої правди.

У 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 до хибного . Однак більш чітко писати вищезазначений рядок і все одно повинен бути вирваний компілятором під час оптимізації.

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

Ага так, але що робити, якщо змінна є нульовою? (бул?)

Деякі мови (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" не є точно "true" або "false", результат буде хибним.

У минулому році я зіткнувся з дуже тонкою помилкою, спричиненою таким стилем кодування, який було важко визначити, бо хтось заглядає за такі конструкції. Ви б подумали: "Як це може бути неправильно?" Це ж стосується і таких добре зрозумілих виразів, як "(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++) ...

Так, я це бачив.