forum.boolean.name

forum.boolean.name (http://forum.boolean.name/index.php)
-   Алгоритмика (http://forum.boolean.name/forumdisplay.php?f=21)
-   -   Присвоение в условии (http://forum.boolean.name/showthread.php?t=20454)

ABTOMAT 24.10.2016 15:02

Присвоение в условии
 
А как вы считаете, допустимо ли присвоение в условии?

Говорят, что такой код плохо читаем, но это не так.
Естественно, речь не идёт о хитрожопых записях с подвывертом.



Пример кода, в котором присвоение в условии вполне допуситимо (псевдокод)
Код:

if (countOfHuita = CountAllHuitaEverywhereVeryLong())
{

// Тут где-то понадобится снова знать countOfHuita
// чтобы сделать какое-то действие, рассчитать что-то ещё

}

// Если же countOfHuita равна нулю (и закастится в false),
// делать ничего не требуется

Опрос не анинимный, комментарии к мнению приветствуются.

Nerd 24.10.2016 15:35

Ответ: Присвоение в условии
 
Допустимо, т.к. сокращает повторение сущностей.
Если речь идёт не о коде для каких-нибудь публикаций, где читаемость важнее.

Randomize 24.10.2016 16:12

Ответ: Присвоение в условии
 
Что-то в интернетике все аргументы уровня "ко-ко-ко, легче читать, ко-ко-ко".

Я понимаю, что мы все тут разной квалификации, но вам до сих пор сложно читать код?
А ведь есть и хуже конструкции. Намного более нечитаемые.
Серьёзно? Стаж ничего не даёт? Не обучаемые? Не грустите, есть много других профессий.

Невнимательно прочитал = плохой программист.

Andvrok 24.10.2016 17:14

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Randomize (Сообщение 309466)
Невнимательно прочитал = плохой программист.

Вот это вот.

impersonalis 24.10.2016 17:29

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Randomize (Сообщение 309466)

Невнимательно прочитал = плохой программист.

Вывод правильный. Непонятно, зачем усложнять жизнь, провоцируя возможность неправильного прочтения. Ну, утрируя: можно использовать переменные с именами a, b, c - они же короче.

По теме: думается, без конкретики - общо - ответить сложно. Лично я, последнее время, опасаюсь, что транслятор прохлопает и не оптимизирует участок кода (или наоборот -некстати), поэтому стараюсь чётко указывать в какой момент понадобился результат вызова функции, где и сколько его надо удерживать. Особенно, если потом, внезапно, кусок будет выполняться в отдельном потоке или семантика функции слегка изменится (кеширование). Сравни
Код:

for(int i=0;i<SizeOfList();i++)
и
Код:

int ListSize=SizeOfList();
for(int i=0;i<ListSize;i++)

С тем же объявлением счётчика в заголовке: одни трансляторы его видят после цикла, другие - нет. Приходится давать ему осмысленное имя и высовывать до цикла.

В примере АВТОМАТ-а - всё выглядит опрятно (и я с MFC впитал такой код). Пока не понадобится дописать ещё несколько условий. Потом транслятор оптимизирует вычисление условий (например, в ситуации 1 OR x - x можно не вычислять) и уже нет гарантии, что функция CountAllHuitaEverywhereVeryLong() будет всегда вызваться, а ведь её результат может быть необходим.

А если транслятор очень болезненно реагирует на неявные касты? А если в ходе рефакторинга поменяется тип возвращаемого значения или появится конструктор, который может быть неявно вызван для приведения - так что каст будет работать не так, как ожидается?

В одном учебнике, автор настоятельно советовал, например, обязательно ставить скобки, обособляя тело цикла или then-часть из одного условия.

Этот приём (присваивание в условии) как эллипсис: с одной стороны - очень удобно и, в общем-то, интуитивно понятно, с другой - чуть зазеваешься и готово!

Резюмируя: и да, и нет - всё хорошо к месту.

impersonalis 24.10.2016 17:56

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Randomize (Сообщение 309466)
Невнимательно прочитал = плохой программист.

Меня чот задело. Простите, конечно, но наивное рассуждение со стороны писателя, а не читателя кода.
Я тут окунулся в пучину древних кодов на Паскалях и прочем. Долго думал - ЧТО ж в них так отталкивает? ЧТО такое притаскивают из них с собой дядьки-инженеры в Си/Си++, будто деревенское "ероплан" в доклад на заседании академии?
А вот что: привычку ковыряться, извините, в г... Полное отсутствие понимания, что "запрогать" это не "переписать офигенных размеров формулы в строчку". Что писать надо не примитивно, но просто. И что хороший код - безопасен: в нём просто-таки нельзя отрезать палец на станке, но не потому, что висит табличка "пальцы не сувать!", а потому, что станок не будет работать, пока не будет опущен защитный экран.

Да - уметь читать чужой бред - это хорошо и похвально, но самому такое воспроизводить - мазохизм.

И да - это не про пример из поста АВТОМАТ-а. Это - к процитированной фразе.

Knightmare 24.10.2016 21:11

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Randomize (Сообщение 309466)
Что-то в интернетике все аргументы уровня "ко-ко-ко, легче читать, ко-ко-ко".

Я понимаю, что мы все тут разной квалификации, но вам до сих пор сложно читать код?
А ведь есть и хуже конструкции. Намного более нечитаемые.
Серьёзно? Стаж ничего не даёт? Не обучаемые? Не грустите, есть много других профессий.

Невнимательно прочитал = плохой программист.

Действительно, а еще можно не юзать отступы и вообще весь код в одну строку писать, чо не программист чтоле раз прочитать не можешь? Алсо когда код сложнее hello world попробуй-ка сразу понять, это там присвоение специально, или автор облажался тупо. Если уж приперло, то есть два варианта, первый:
Код:

if ((x = foo()) != 0) // ну или if ((x == foo())) если буквы надо бегать на рынок покупать и они дефицит
{
    ...
}

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

if (int x = foo())
{
    ...
}

Ясно и понятно что присвоение тут и надо, но понятное дело что область видимости будет другая у int х, подойдет не всегда.

moka 25.10.2016 00:37

Ответ: Присвоение в условии
 
Я не сторонник усложнений, поэтому over-engineering присекаю на корню, но и супер-"упрощений" - тоже избегаю, т.к. это уходит в другие крайности, где у нас всякие coffeescript'ы изобритают и т.п. чушь.
Если писать с вызовом функции:
PHP код:

if (bar baz()) 

И далее другой разраб прибегает, и что-то в функцию вставляет, с ожиданием что она ведь при тесте вызывается - значит всё ок.
Затем прибегает третий, и вставляет условие:
PHP код:

if (foo && bar baz()) 

И тут вызов baz'а, стал не стабильным, при этом зависит от пожеланий foo. Третий разраб давай думать, первый скорее всего тоже.
Ну тут они разобрались, и вынесли вызов функции и условие, либо содержимое функции.

Так вот, усложнил ли код первый разраб поставив всё в одну строку? Нет, но усложнил жизнь в будущем.
При этом разница в чтении ну чертовски мизерная, и читаемость двух строк не снижается нифига.

Я стараюсь придерживаться простоты - делаешь дело, не отвлекайся: вызов функции с присвоением - это одно дело. Проверка результата - это другое.

Randomize 25.10.2016 03:08

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Knightmare (Сообщение 309474)
Действительно, а еще можно не юзать отступы и вообще весь код в одну строку писать

Отступов бояться - ide не юзать.
Советую полностью переложить кодоформатирование на машину. Глупо тратить время на то, что робот неплохо сделает за тебя.
Кстати порой таки приходится править минифицированный код - это не трудно.

Цитата:

Сообщение от Knightmare (Сообщение 309474)
Код:

if ((x = foo()) != 0) // ну или if ((x == foo())) если буквы надо бегать на рынок покупать и они дефицит

Почти каждый день вижу подобные конструкции, вот более реальный пример:
PHP код:

if (FALSE !== ($f fopen("hui.txt""r")) 


Продолжая тему, бывает, например, и такое:
PHP код:

while($res $ds->getNextPeaceOfShit()){
 
/* */ 


В цикле тоже моветон?

moka 25.10.2016 04:29

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Randomize (Сообщение 309484)
Продолжая тему, бывает, например, и такое:
PHP код:

while($res $ds->getNextPeaceOfShit()){
 
/* */ 


В цикле тоже моветон?

Вот while для подобной структуры чаще встречается да, и в данном случае это упрощает ситуацию. В большинстве вариантов условие в while не усложняют, а усложняют логику в getNextPeaceOfShit. Если не могут, то анонимный метод выше и поехали.

А вообще в ES7 с await такие цикли ещё красивее делают вместе с асинхронным кодом выраженным в функциональной форме.

Но на самом деле, всё это х*йня, заместо того чтобы болтать как нужно писать, лучше бы код писали. Работал я в одной команде хипстеров, там стиль написания вообще по жёсткому разными проверяльщиками пропускали и даже PR не проходили если не подчиняешься стилю.
И потом на обедах устраивали холивары как можно и как нельзя писать код. Я на это со стороны смотрел, и думал "ну на*уй, лучше бы код писали и деплоили как есть". Но нет, деплой процесс затягивается на 20 минут на рыло, и цепочку из 3ех хипстеров, в итоге в продакшен что-то попадает только через несколько дней.

У нас в PlayCanvas, в продакшн пушаю код за 3-5 минут после прочтения письма от клиента с описанием бага.
Если бы писали бы код как мудаки или хипстерили о том как нужно писать - ничего этого не было бы.

Knightmare 25.10.2016 10:50

Ответ: Присвоение в условии
 
Цитата:

Сообщение от Randomize (Сообщение 309484)
Почти каждый день вижу подобные конструкции, вот более реальный пример:
PHP код:

if (FALSE !== ($f fopen("hui.txt""r")) 


Ну епт, о том и речь, тут понятно что это не опечатка, хотя для fopen конечно в принципе это не важно, потому что никто не будет сравнить что-то с ее результатом.
Цитата:

Сообщение от Randomize (Сообщение 309484)
Продолжая тему, бывает, например, и такое:
PHP код:

while($res $ds->getNextPeaceOfShit()){
 
/* */ 


В цикле тоже моветон?

Аналогично надо заворачивать в явное условие.


Часовой пояс GMT +4, время: 06:40.

vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot