Присвоение в условии
А как вы считаете, допустимо ли присвоение в условии?
Говорят, что такой код плохо читаем, но это не так. Естественно, речь не идёт о хитрожопых записях с подвывертом. Пример кода, в котором присвоение в условии вполне допуситимо (псевдокод) Код:
if (countOfHuita = CountAllHuitaEverywhereVeryLong()) |
Ответ: Присвоение в условии
Допустимо, т.к. сокращает повторение сущностей.
Если речь идёт не о коде для каких-нибудь публикаций, где читаемость важнее. |
Ответ: Присвоение в условии
Что-то в интернетике все аргументы уровня "ко-ко-ко, легче читать, ко-ко-ко".
Я понимаю, что мы все тут разной квалификации, но вам до сих пор сложно читать код? А ведь есть и хуже конструкции. Намного более нечитаемые. Серьёзно? Стаж ничего не даёт? Не обучаемые? Не грустите, есть много других профессий. Невнимательно прочитал = плохой программист. |
Ответ: Присвоение в условии
Цитата:
|
Ответ: Присвоение в условии
Цитата:
По теме: думается, без конкретики - общо - ответить сложно. Лично я, последнее время, опасаюсь, что транслятор прохлопает и не оптимизирует участок кода (или наоборот -некстати), поэтому стараюсь чётко указывать в какой момент понадобился результат вызова функции, где и сколько его надо удерживать. Особенно, если потом, внезапно, кусок будет выполняться в отдельном потоке или семантика функции слегка изменится (кеширование). Сравни Код:
for(int i=0;i<SizeOfList();i++) Код:
int ListSize=SizeOfList(); В примере АВТОМАТ-а - всё выглядит опрятно (и я с MFC впитал такой код). Пока не понадобится дописать ещё несколько условий. Потом транслятор оптимизирует вычисление условий (например, в ситуации 1 OR x - x можно не вычислять) и уже нет гарантии, что функция CountAllHuitaEverywhereVeryLong() будет всегда вызваться, а ведь её результат может быть необходим. А если транслятор очень болезненно реагирует на неявные касты? А если в ходе рефакторинга поменяется тип возвращаемого значения или появится конструктор, который может быть неявно вызван для приведения - так что каст будет работать не так, как ожидается? В одном учебнике, автор настоятельно советовал, например, обязательно ставить скобки, обособляя тело цикла или then-часть из одного условия. Этот приём (присваивание в условии) как эллипсис: с одной стороны - очень удобно и, в общем-то, интуитивно понятно, с другой - чуть зазеваешься и готово! Резюмируя: и да, и нет - всё хорошо к месту. |
Ответ: Присвоение в условии
Цитата:
Я тут окунулся в пучину древних кодов на Паскалях и прочем. Долго думал - ЧТО ж в них так отталкивает? ЧТО такое притаскивают из них с собой дядьки-инженеры в Си/Си++, будто деревенское "ероплан" в доклад на заседании академии? А вот что: привычку ковыряться, извините, в г... Полное отсутствие понимания, что "запрогать" это не "переписать офигенных размеров формулы в строчку". Что писать надо не примитивно, но просто. И что хороший код - безопасен: в нём просто-таки нельзя отрезать палец на станке, но не потому, что висит табличка "пальцы не сувать!", а потому, что станок не будет работать, пока не будет опущен защитный экран. Да - уметь читать чужой бред - это хорошо и похвально, но самому такое воспроизводить - мазохизм. И да - это не про пример из поста АВТОМАТ-а. Это - к процитированной фразе. |
Ответ: Присвоение в условии
Цитата:
Код:
if ((x = foo()) != 0) // ну или if ((x == foo())) если буквы надо бегать на рынок покупать и они дефицит Код:
if (int x = foo()) |
Ответ: Присвоение в условии
Я не сторонник усложнений, поэтому over-engineering присекаю на корню, но и супер-"упрощений" - тоже избегаю, т.к. это уходит в другие крайности, где у нас всякие coffeescript'ы изобритают и т.п. чушь.
Если писать с вызовом функции: PHP код:
Затем прибегает третий, и вставляет условие: PHP код:
Ну тут они разобрались, и вынесли вызов функции и условие, либо содержимое функции. Так вот, усложнил ли код первый разраб поставив всё в одну строку? Нет, но усложнил жизнь в будущем. При этом разница в чтении ну чертовски мизерная, и читаемость двух строк не снижается нифига. Я стараюсь придерживаться простоты - делаешь дело, не отвлекайся: вызов функции с присвоением - это одно дело. Проверка результата - это другое. |
Ответ: Присвоение в условии
Цитата:
Советую полностью переложить кодоформатирование на машину. Глупо тратить время на то, что робот неплохо сделает за тебя. Кстати порой таки приходится править минифицированный код - это не трудно. Цитата:
PHP код:
Продолжая тему, бывает, например, и такое: PHP код:
|
Ответ: Присвоение в условии
Цитата:
А вообще в ES7 с await такие цикли ещё красивее делают вместе с асинхронным кодом выраженным в функциональной форме. Но на самом деле, всё это х*йня, заместо того чтобы болтать как нужно писать, лучше бы код писали. Работал я в одной команде хипстеров, там стиль написания вообще по жёсткому разными проверяльщиками пропускали и даже PR не проходили если не подчиняешься стилю. И потом на обедах устраивали холивары как можно и как нельзя писать код. Я на это со стороны смотрел, и думал "ну на*уй, лучше бы код писали и деплоили как есть". Но нет, деплой процесс затягивается на 20 минут на рыло, и цепочку из 3ех хипстеров, в итоге в продакшен что-то попадает только через несколько дней. У нас в PlayCanvas, в продакшн пушаю код за 3-5 минут после прочтения письма от клиента с описанием бага. Если бы писали бы код как мудаки или хипстерили о том как нужно писать - ничего этого не было бы. |
Ответ: Присвоение в условии
Цитата:
Цитата:
|
Часовой пояс GMT +4, время: 20:32. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot