Честная задания


Я часто спорю с голосами в своей правоте о необходимости назначения в случае, если заявление (или эквивалент), имеющие смысл этого:

if($thing = someFunction()){
   //do stuff
}

Вместо этого:

$thing = someFunction();
if($thing){
   //Do stuff
}

Часть меня говорит, что это плохая практика, потому что:

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

Но голоса его хорошо, потому что:

  • Меньше линий, выглядит чище.
  • На практике не такая уж и редкость (С/с++, PHP).
  • Переменная получает больше семантики (как правило, не используется за пределами если сфера)
  • Это на самом деле легко привыкнуть, читать ее и не пропустить его, увидев его пару раз.

Так, может быть право голоса? Или это необычная практика?



521
5
задан 26 июня 2011 в 11:06 Источник Поделиться
Комментарии
4 ответа

Я согласен с тем, что @ФГР говорит.

Еще один способ, который я видел:

if (($thing = some_function()) == true) {
do_something();
}

Я все еще утверждаю, что второй способ представить (цессии перед if заявление). Я считаю, что это более читабельным, поскольку уступка отделена от сравнения. Есть идиоматические исключения, например, в C:

if ((ptr = malloc(sizeof(int) * size)) == null) {
run_away_screaming();
}

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

(

Все это предполагает, что возвращаемое значение не логическое && возвращаемое значение используется в другом месте. Если нет, следует:

if (some_function()) {
do_something();
}

Просто перестраховывается :)

)

3
ответ дан 27 июня 2011 в 02:06 Источник Поделиться

Я предпочитаю второй способ, как это сделать (не имея его в Если-п.):


На практике не такая уж и редкость (С/с++, PHP).

Есть много плохой практики там. Просто обычный не значит, что это хорошо.


Переменная получает больше семантики (как правило, он не используется за пределами если сфера)

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


Меньше линий, выглядит чище.

Удалить все комментарии из кода - это даже меньше линий. Значит ли это, что лучше?


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

Вы уже дали аргумент против этого сами:


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

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

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

2
ответ дан 27 июня 2011 в 12:06 Источник Поделиться

Вот некоторые серьезные проблемы, почему присваивание внутри условия плохие:


  1. Классический == против = новичок ошибку. Вместо того, чтобы принять собой образец стиля кодирования, чтобы предотвратить эту ошибку, т. е. если(нуль == ВАР), просто избежать присваивание внутри условия.

  2. Присваивание внутри условия затрудняет компилятор или статический анализатор, чтобы найти фактические ошибки в вашем коде.

  3. Порядок вопросов оценки. Для большинства операторов в C/C++, в порядке оценки реализации определенного поведения. Это означает, что вы не можете знать, в левую или правую сторону = сначала вычисляется, которые могут или не могут привести к фатальным ошибкам. Типичный пример, возможно, роковая ошибка Х=Y=0;, что компилятор волен интерпретировать как "поставить неинициализированный мусор в Х, то поставьте 0 в М". Ошибки, как это более вероятно, произойдет внутри условия.

  4. Неопределенное поведение. Это связано с порядок выдачи оценки выше, но еще более тяжелой. Это происходит, когда вы пишете код, как в то время(ОБР[я] < я++). Это неопределенное поведение, и ваша программа является свободным к краху и сжечь, если код содержит его.
    https://stackoverflow.com/search?q=i%2B%2B+неопределена+поведение

Причина 1 и 2 выше, взяты из широко-recogniced отраслевой стандарт Мисра-с:2004, который запрещает присваивание внутри условия в правиле 13.1. Присваивание внутри условия тоже запрещены сертификат c, EXP18-С.

2
ответ дан 8 июля 2011 в 01:07 Источник Поделиться

Ответ действительно зависит от того, кто будет просматривать код. В то время как оба метода являются правильными и приемлемыми, если вы работаете с неопытного/начинающего программиста уровне, то это позволит облегчить жизнь каждого, чтобы использовать:

$thing = someFunction();
if($thing){
//Do stuff
}

Однако, если ваш код будет смотреть на средне-опытных программистов, то они не должны иметь никаких проблем в расшифровке:

if($thing = someFunction()){
//do stuff
}

В конце дня, что является более важным является время выполнения вашего кода. Оба метода дают за O(1) Время выполнения, таким образом, либо может быть использован в зависимости от уровня программиста будет просмотр кода и т. д.

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

0
ответ дан 13 июля 2011 в 05:07 Источник Поделиться