Чи не "if (0 == value) ..." приносить більше шкоди, ніж користі? [зачинено]

Це одна з речей, яку я найбільше ненавиджу, коли бачу це в чужому коді. Я знаю, що це означає і чому деякі люди роблять це саме так ("що робити, якщо я випадково поставив" = "замість?"). Для мене це дуже подобається, коли дитина спускається по сходах, рахуючи кроки вголос.

У всякому разі, ось мої аргументи проти цього:

• Це порушує природний потік читання програмного коду. Ми, люди, кажемо «якщо значення дорівнює нулю», а не «якщо нуль - це значення».
• Сучасні компілятори попереджають вас, коли у вас є завдання у вашому стані чи фактично, якщо ваш стан складається саме з того завдання, яке, так, виглядає так само підозріло
• Ви не повинні забувати ставити подвійний '=', коли ви порівнюєте значення, якщо ви програміст. Ви можете також забути поставити "!" при тестуванні нерівності.

А, так, "Yoda conditionals" ("Якщо нульове значення є, виконайте цей код!"). Я завжди вказую на тих, хто стверджує, що вони "кращі" в таких інструментах, як ворсинка (1). Ця проблема вирішується з кінця 70-х років. Більшість сучасних мов навіть не компілюють такий вираз if(x = 10), як вони відмовляються примушувати результат присвоєння булеві.

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

Це неприємно, бо накладає невеликий, але помітний ментальний податок.

Люди читають зліва направо практично на всіх мовах програмування (і на більшості природних мов).

Якщо я бачу 123 == x, я подумки розбираю це:

• 123- і що? неповна інформація.
• == - ну, 123 - 123, навіщо тестувати ...
• x- гаразд, так це нас хвилює. Тільки зараз у мене є контекст.
• Поверніться до розгляду 123і чому х порівнюється з ним.

Коли я бачу x == 123ментальний розбір:

• x- Надає контекст, я знаю, про яку умову йдеться. Я можу вирішити ігнорувати решту. Виходячи з попереднього потоку, я добре розумію, чому і що має бути (і здивуюся, якщо це інакше).
• == - Я так думав.
• 123 - Так.

Зрив невеликий (на простому прикладі), але я завжди це помічаю.

Поставити значення спочатку може бути хорошою ідеєю, якщо ви хочете звернути на нього увагу, наприклад if (LAUNCH_NUKES == cmd). Зазвичай це не є наміром.

Шкідливий? Ні. Це працює в будь-якому випадку.

Погана практика? Дискусійний, у кращому випадку. Це просте оборонне програмування.

Варто втратити сон? Ні.

Це в основному флеймбайт.

Ні, це не приносить більше шкоди, ніж користі. Простий.

Більше слів?

Аргумент компілятора? Е-е-е, можливо, - не вкладайте занадто багато віри в компілятор, щоб врятувати вас від себе.

«Ви не повинні забувати» - добре Дух - ні, звичайно , ви не повинні тим , що я втомився, я кодування весь день я повинен був використовувати дві різні мови , а іноді, просто іноді, будучи людини я роблю помилка.

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

Важко читати? Ви скаржитеся, що гідний програміст повинен мати == провідний провід (що робить усілякі погані припущення), але той самий гідний програміст не може прочитати значення 0 == ??

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

Я б не назвав це шкодою, але це неприємно. Так що ні, я б не сказав, що це робить.

Я ніколи не відчував, що ціле "що, якщо я забуду a =?" ніколи насправді тримав велику вагу. Так, ви можете зробити друк, але всі ми робимо помилки, здається, що нерозумно змінити весь стиль кодування, тому що ви боїтеся помилитися. Чому б не зробити всі ваші змінні та функції усіма малими літерами, не маючи пунктуації, тому що ви можете забути щось з великої літери або забути підкреслення одного дня?

Деякі люди використовують це, щоб зрозуміти, що саме робить умовний. Наприклад:

Спосіб 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Спосіб 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Деякі люди вважають, що другий приклад є більш стислим, або зворотні аргументи ілюструють точку тесту (умовної) перед самим тестом.

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

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

Для мене це просте кондиціонування. Як хтось, хто навчився (у 90-х) C та C ++, я звик до нього і досі ним користуюсь, хоча причини є меншими.

Після того, як ви "умовні" подивитися на ліву сторону на "постійну", це стає другою природою.

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

Я повністю згоден з / у відповідь Вонко.

Один з випадків, коли мені здається корисним, це те, коли змінна частина значень if досить довга, а бачення значень полегшує читання коду. Кращими прикладами цього є пунктирні мови простору імен.

Наприклад, щось, над чим я працював з одним входом, мала ситуацію, коли у вас могли бути два одночасні сеанси, якщо певний тип помилок трапився і було відновлено певним чином, тому я повинен додати обробник для нього, який знаходився всередині, якщо це виглядало щось на зразок цього:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

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

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

Я дещо тримаюсь із цим. Порада, яку я дотримувався (можливо, з Code Complete), - зберігати те, що має бути нижчим значенням зліва в порівняннях. Я обговорював це з колегою раніше, і він думав, що це щось на зраді, але я дуже звик до цього.

Тому я б сказав:

if ( 0 <= value )

Але я також сказав:

if ( value <= 100 )

Рівність Я, як правило, перевірятиму зі змінною зліва, хоча вона просто читабельніша.