Недавно во время code review на моем проекте у меня возникли разногласия с коллегами. Касались они следующего кода:
Сразу несколько действительно хороших разработчиков считали этот код абсолютно неприемлемым. Особенно показательным был аргумент моего коллеги Тимофея: «Assignments в conditions — это зло, об этом рассказывают на первой лекции по программированию». Возможно, но т.к у меня небыло ни одной лекции по программированию, предлагаю все-таки разобраться почему это зло.
Итак, все вы знаете как работают условия и операторы сравнения в php.
В примере ниже значение переменной $var приводится к булевскому, и если оно равно true условие выполняется.
В этом примере сравниваются значения переменной $var и результата выполнения foo() и если они эквивалентны — условие выполняется.
Здесь в условии переменной $var присваивается результат выполнения foo(), после чего значение $var приводится к булевскому, и если оно равно true — условие выполняется.
Последний пример хоть и допустим в php, но действительно плохо читается, т.к в условии отсутствуют операторы сравнения. Нередко такой код свидетельствует об ошибке, и программист на самом деле имел ввиду
При сравнение переменной с булевским значением с учетом типа часто пишут так
Делается это именно для того, чтобы избежать случайного присваивания переменно $var значения true, например вот такого
IDE тоже стараются предупредить разработчика, если он использует присваивание в условии. Вот пример из Eclipse
Вернемся к коду, который вызвал разногласия
Здесь переменной $var присваивается результат выполнения foo(), который сравнивается с false. Разница этого примера с тем, который я написал в Eclipse в том, что здесь в явном виде присутствует основной элемент условия — сравнение. Такой код прекрасно читается и не оставляет пространства для возможных опечаток. Eclipse считает его валидным
Использовать такой код удобно, когда переменная, определенная в условии, будет использоваться только внутри конструкции if. Во всех других случаях лучше выносить инициализацию переменной из условия.
if (false == ($var = foo())){...}
Сразу несколько действительно хороших разработчиков считали этот код абсолютно неприемлемым. Особенно показательным был аргумент моего коллеги Тимофея: «Assignments в conditions — это зло, об этом рассказывают на первой лекции по программированию». Возможно, но т.к у меня небыло ни одной лекции по программированию, предлагаю все-таки разобраться почему это зло.
Итак, все вы знаете как работают условия и операторы сравнения в php.
В примере ниже значение переменной $var приводится к булевскому, и если оно равно true условие выполняется.
if ($var){...}
В этом примере сравниваются значения переменной $var и результата выполнения foo() и если они эквивалентны — условие выполняется.
if ($var == foo()){...}
Здесь в условии переменной $var присваивается результат выполнения foo(), после чего значение $var приводится к булевскому, и если оно равно true — условие выполняется.
if ($var = foo()){...}
Последний пример хоть и допустим в php, но действительно плохо читается, т.к в условии отсутствуют операторы сравнения. Нередко такой код свидетельствует об ошибке, и программист на самом деле имел ввиду
if ($var == foo()){...}
При сравнение переменной с булевским значением с учетом типа часто пишут так
if (true === $var){...}
Делается это именно для того, чтобы избежать случайного присваивания переменно $var значения true, например вот такого
if ($var = true){...}
IDE тоже стараются предупредить разработчика, если он использует присваивание в условии. Вот пример из Eclipse
Вернемся к коду, который вызвал разногласия
if (false == ($var = foo())){...}
Здесь переменной $var присваивается результат выполнения foo(), который сравнивается с false. Разница этого примера с тем, который я написал в Eclipse в том, что здесь в явном виде присутствует основной элемент условия — сравнение. Такой код прекрасно читается и не оставляет пространства для возможных опечаток. Eclipse считает его валидным
Использовать такой код удобно, когда переменная, определенная в условии, будет использоваться только внутри конструкции if. Во всех других случаях лучше выносить инициализацию переменной из условия.
