ретурн почти гото, втыкая десять ретурнов ты превращаешь тело процедуры в сыр. не гарантировано, что значение из свича всегда должно будет отправляться на ретурн до конца жизни этой вселенной. ну и насчёт читабельности — ты съебал, после тебя приходит чел и начинает распутывать вермишель из ретурнов, оверюзбл.
4.
2538
→ 2538/220.05.2012 22:48 tertium non datur
вообще по теме какой инструмент лучше — тот что свободнее или несвободнее (в данном случае ЯП) можно долго спорить.
надо определиться с целью, цель — наваять алгоритм. при ваянии алгоритма мы имеем язык (правила) и исполнителя. допустим, что исполнитель идеально точный. тогда, успешность решения зависит от кодера. кодер — неидеальный, то есть, может ошибаться. кодер может ошибаться, но для исполнителя в общем случае получим три вида ошибок - времени компиляции — неудовлетворены правила языка, ну тут просто, исполнитель сам их укажет. - времени исполнения — неудовлетворены правила _реализации_ исполнителя, вот тут появляется случай из оп-поста, про missing return. свободный инструмент позволит такой ошибке появиться, но он же позволит её обнаружить в большинстве случаев. - логическая. — тут алгоритм для исполнителя формально верен, но он имеет своим результатом совсем не то.
так вот, когда у нас много ретурнов мы переводим ошибку со второго уровня на третий, то есть, давая нам свободу, исполнитель работает по заведомо некорректной программе всилу того, что он идеальный, а кодер — с ошибкой. Так вот, понимая это, я, как кодер с ошибкой вообще предпочту перевести подобную ошибку, то есть, разрыв в структуре программы, на первый уровень, когда missing return тупо не даст мне довести компиляцию до конца. а если при этом позволен будето только один ретурн — фактически компилер исправит ошибку за меня. так вот, а сейчас, возвращаясь в реальность, и имея инструмент в котором МОЖНО допустить ошибку, я предпочту лишний раз подумать (обосновать) над необходимостью такого ощибкоопасного средства. Швабодка и всё такое.
ещё раз повторюсь, тема обширная. возможно даже, выходящая за рамки быдлокодерства и прочих ойти-контекстов.
ну ты просто-таки неимоверно пиздишь. то есть, да, есть return, который при его отсутствии сигнализирует во время компиляции о неработоспособности функции. но return этот делает какой-нибудь "return ret_val;", и, по сути, return внутри switch-блока ты заменяешь на присвоение ret_val нужному значению. и компилятор тебе ничего об отсутствии присвоения в одном из блоков ничего не скажет.
в общем, кроме аргумента "нам может потребоваться дополнительное действие над ret_val" (который может "довешиваться" также дополнительной функцией, если эта и так достаточно ясно выражает логическую единицу), в остальном ты меняешь шило на мыло, при этом еще и убедив себя, что делаешь мир лучше.
хыхы, после долгого обсуждения данной темы со всякими научными работниками, преподавателями и прочими не самыми глупыми людьми приходит крутой чел из псто и растележивает капитанскую хуету. как бы животик не надорвать от смеха.
ну если ты так уверен что прав, объясни свою правоту. от того, что тебе сказали что-то умные люди не значит, что ты что-то понял. может придется побежать переспросить у умных дядь, о которых ты так нежно пишешь.
- времени исполнения — неудовлетворены правила _реализации_ исполнителя, вот тут появляется случай из оп-поста, про missing return. свободный инструмент позволит такой ошибке появиться, но он же позволит её обнаружить в большинстве случаев.
что ты имел в виду? что если у нас один return — значит при его отсутствии компилятор выдаст предупреждение missing return. так? или что-то другое?
как можно доказать правоту человеку, который твой оппонент, лол. тем более в вопросе, который формально нигде не озвучивался и готовых решений для него нет. ты например продемонстрировал уровень "понимания", в ответе /5 что тебе после этого можно объяснить, если всё непонятное ты скинул в раздел "делаешь мир лучше" (то есть, хуйня). очевидно, что сравнивая твои слова со словами той группы людей, в которой обсуждается эта идея, ты выглядишь не таким крутым, каким кажешься себе сейчас.
мне не важен уровень крутости, почему-то ты то упоминаешь каких-то умных дядек, то судишь об уровне человека, то обзываешь обезьяной, хотя ничего из этого прямого отношения к обсуждаемой теме не имеет (а лишь говорит о том, какой ты долбоёб).
так вот, ты можешь объяснить, чем замена множественных return'ов на собирание в переменную вида ret_val и потом единый её return лучше? если ты считаешь, что мы переводим с одного уровня ошибку на другой — я, как мне показалось, объяснил тебе, что это не так.
понимаешь? мне абсолютно похуй, сколько раз ты лично поставишь ретурн, и как ты составляешь тело процедуры. или даже, мне похуй как "принято" делать среди местных макак, потому что это "принято" не имеет никаких оснований, кроме коллективного бессознательного опыта. но есть люди которые пытаются формализовать такие вещи, очевидно, для этого нужно выработать систему понятий. при этом, начинать надо не с "удобства" для макаки, а с базовых вещей. ну например, есть контора (жаба, плюсцы), в которой после обсуждения было принято правило, которое заставляло людей ставить один ретурн в конце, и один существенный тип ошибок (нарушение структуры тела процедуры) был устранён.
в любой беседе есть момент, когда происходит переход от разумного к животному. если ты такой недолбоёб, ты должен был постараться выбрать иной способ построения своего текста в /5 что же ты ожидал в ответ, на слова "ты пиздишь", лол?
что? вообще-то я перестал следить за своим тоном из-за вот этого твоего сообщения #ogeets/5 . иначе слова "пиздишь", "долбоёб" и прочие просто так не прозвучали бы в твою сторону.
ну вот я тебе о том и говорю, что возьми простыню, которой ты назвал "в твоём случае получаем", и замени слово "возврат" на слово "в переменную-аккумулятор возвращаемого значения помещаем возвращаемое значение". получится, что вместо возврата мы получим ret_val = 123, плюс необходимость пройти в конец простыни и убедиться, что этот самый ret_val никак не модифицируется более.
"действия+проверка промежуточных условий" полностью покрывает всю простыню, кроме проверки постусловий и возврата. надеюсь никто не спорит, что проверять постусловия надо? в данном случае не нужно проверять постусловия перед каждым возвратом. а ошибка непроинициализированной переменной результата это уже другой тип ошибок, и не думаю, что куча ретурнов это хороший способ избежать ошибки.
естественно, речь идёт о ситуации, где нет необходимости проверять пост-условия. иначе причиной избавления от множественных return'ов может будет банальное избавление от копипасты.
в том отношении, в котором я его употребил — да. иначе я бы этого не делал. спрашивал про необходимость доказывать в том смысле, что, как мне кажется, необходимо доказывать именно использование одного return'а (вместо множества), т.к. множественный return — вполне легальное средство языка.
к вопросу о свободе действий. это примерно как стрельба по людям, ведь реальность не мешает стрелять в людей, и только другие люди, осознав опасность этого, решают ввести искусственные ограничения на стрельбу, которые выставляют условия для этого. поэтому я не говорю что ретурны это плохо или хорошо, я описываю возможные ошибки и средства их устранения, предотвращения.
да, я понял. а я описываю другие, точно так же возможные ошибки, возникающие при твоих "ограничениях", и о том, что замена множественного return'а на один делает только хуже читаемость кода.
вот я и пытаюсь во всю понять, от каких же конкретно ошибок нас избавляет замена множественного return'а на единичный. чувствую, скоро придется тратить время и код писать настоящий, иначе ну никак не вижу этих преимуществ.
кроме пост-условий, о которых (как мне было очевидно) речь не идёт. если нужны пост-условия именно в рамках этой же функции (а не функции-обёртки над этой), то я согласен, множественные return'ы плохо — но по причине копипасты, естественно.
Попробуй в своей основной деятельности перейти на способ построения алгоритмов без кучи ретурнов (и аналогов, типа выхода из середины цикла). ведь все знают, как НЕ юзать все эти недо-гото, пусть даже они и более предсказумы. А искусственные примеры всегда будут неполны, да и вот так сразу не поймёшь, что будет показательным в данной ситуации.
Тут есть конечно, доля субъективного восприятия, ну впрочем как и у всех людей. Надо понимать, что отделить разумное от животного довольно трудно, и на самом деле может оказаться так, что уверенность в правильности одного из методов это тупо нежелание менять привычный и ненапрягающий рабочий процесс.
Я вот не утверждаю, что способ описаный в треде стопудов верный, и понятно, что с переменной результата (да и нет гарантии, нужна ли она будет, ведь изначально функция строилась под использование ретурнов), придут другие типы ошибок, но вот оценку СТРАШНОСТИ и вообще, сравнение результатов того или иного применённого метода, я щитаю, не получится выполнить настолько просто и быстро, чтобы вот так за один день решить, что тебе и с ретурнами неплохо живётся.
С другой стороны, избегание ошибок чисто за счёт ограничения свободы ничуть не более напрягает, чем слежение разума за корректностью свободного кода. По крайней мере ретурны меня не беспокоят, потому что их тупо нет.
всё, что я хочу понять — от какого же типа ошибок спасает избегание множественных ретурнов. ты вот употребил "нарушение структуры тела процедуры". я так понял, что под структурой тела процедуры ты имеешь в виду
структура процедуры начало проверка предусловий действие+проверка промежуточных условий проверка постусловий возврат
если это считать за структуру процедуры, то конечно ты прав и её структура нарушается. но тогда непонятно зачем создатели языка впринципе сделали return, а не, скажем, "возврат == последнее выражение". мне кажется, что return в любом месте процедуры по мнению авторов ЯП как раз входят в её структуру, а искуственное избавление — лишь имитация этих множественных return'ов при помощи вспомагательных переменных ("руками").
27 comments
recommend
bookmark
subscribe
ответ мне запили
ретурн почти гото, втыкая десять ретурнов ты превращаешь тело процедуры в сыр.
не гарантировано, что значение из свича всегда должно будет отправляться на ретурн до конца жизни этой вселенной.
ну и насчёт читабельности — ты съебал, после тебя приходит чел и начинает распутывать вермишель из ретурнов, оверюзбл.
как я поддерживаю
вообще по теме какой инструмент лучше — тот что свободнее или несвободнее (в данном случае ЯП) можно долго спорить.
надо определиться с целью, цель — наваять алгоритм. при ваянии алгоритма мы имеем язык (правила) и исполнителя.
допустим, что исполнитель идеально точный.
тогда, успешность решения зависит от кодера.
кодер — неидеальный, то есть, может ошибаться.
кодер может ошибаться, но для исполнителя в общем случае получим три вида ошибок
- времени компиляции — неудовлетворены правила языка, ну тут просто, исполнитель сам их укажет.
- времени исполнения — неудовлетворены правила _реализации_ исполнителя, вот тут появляется случай из оп-поста, про missing return. свободный инструмент позволит такой ошибке появиться, но он же позволит её обнаружить в большинстве случаев.
- логическая. — тут алгоритм для исполнителя формально верен, но он имеет своим результатом совсем не то.
так вот, когда у нас много ретурнов мы переводим ошибку со второго уровня на третий, то есть, давая нам свободу, исполнитель работает по заведомо некорректной программе всилу того, что он идеальный, а кодер — с ошибкой. Так вот, понимая это, я, как кодер с ошибкой вообще предпочту перевести подобную ошибку, то есть, разрыв в структуре программы, на первый уровень, когда missing return тупо не даст мне довести компиляцию до конца. а если при этом позволен будето только один ретурн — фактически компилер исправит ошибку за меня.
так вот, а сейчас, возвращаясь в реальность, и имея инструмент в котором МОЖНО допустить ошибку, я предпочту лишний раз подумать (обосновать) над необходимостью такого ощибкоопасного средства. Швабодка и всё такое.
ещё раз повторюсь, тема обширная. возможно даже, выходящая за рамки быдлокодерства и прочих ойти-контекстов.
ну ты просто-таки неимоверно пиздишь. то есть, да, есть return, который при его отсутствии сигнализирует во время компиляции о неработоспособности функции. но return этот делает какой-нибудь "return ret_val;", и, по сути, return внутри switch-блока ты заменяешь на присвоение ret_val нужному значению. и компилятор тебе ничего об отсутствии присвоения в одном из блоков ничего не скажет.
в общем, кроме аргумента "нам может потребоваться дополнительное действие над ret_val" (который может "довешиваться" также дополнительной функцией, если эта и так достаточно ясно выражает логическую единицу), в остальном ты меняешь шило на мыло, при этом еще и убедив себя, что делаешь мир лучше.
хыхы, после долгого обсуждения данной темы со всякими научными работниками, преподавателями и прочими не самыми глупыми людьми приходит крутой чел из псто и растележивает капитанскую хуету. как бы животик не надорвать от смеха.
тупикал псто, сборище недалёких макак без единой попытки разобрать то, что им говорят.
ну если ты так уверен что прав, объясни свою правоту. от того, что тебе сказали что-то умные люди не значит, что ты что-то понял. может придется побежать переспросить у умных дядь, о которых ты так нежно пишешь.
ну вот смотри. ты написал:
- времени исполнения — неудовлетворены правила _реализации_ исполнителя, вот тут появляется случай из оп-поста, про missing return. свободный инструмент позволит такой ошибке появиться, но он же позволит её обнаружить в большинстве случаев.
что ты имел в виду? что если у нас один return — значит при его отсутствии компилятор выдаст предупреждение missing return. так? или что-то другое?
как можно доказать правоту человеку, который твой оппонент, лол. тем более в вопросе, который формально нигде не озвучивался и готовых решений для него нет. ты например продемонстрировал уровень "понимания", в ответе /5
что тебе после этого можно объяснить, если всё непонятное ты скинул в раздел "делаешь мир лучше" (то есть, хуйня).
очевидно, что сравнивая твои слова со словами той группы людей, в которой обсуждается эта идея, ты выглядишь не таким крутым, каким кажешься себе сейчас.
мне не важен уровень крутости, почему-то ты то упоминаешь каких-то умных дядек, то судишь об уровне человека, то обзываешь обезьяной, хотя ничего из этого прямого отношения к обсуждаемой теме не имеет (а лишь говорит о том, какой ты долбоёб).
так вот, ты можешь объяснить, чем замена множественных return'ов на собирание в переменную вида ret_val и потом единый её return лучше? если ты считаешь, что мы переводим с одного уровня ошибку на другой — я, как мне показалось, объяснил тебе, что это не так.
понимаешь? мне абсолютно похуй, сколько раз ты лично поставишь ретурн, и как ты составляешь тело процедуры. или даже, мне похуй как "принято" делать среди местных макак, потому что это "принято" не имеет никаких оснований, кроме коллективного бессознательного опыта.
но есть люди которые пытаются формализовать такие вещи, очевидно, для этого нужно выработать систему понятий. при этом, начинать надо не с "удобства" для макаки, а с базовых вещей.
ну например, есть контора (жаба, плюсцы), в которой после обсуждения было принято правило, которое заставляло людей ставить один ретурн в конце, и один существенный тип ошибок (нарушение структуры тела процедуры) был устранён.
в любой беседе есть момент, когда происходит переход от разумного к животному.
если ты такой недолбоёб, ты должен был постараться выбрать иной способ построения своего текста в /5
что же ты ожидал в ответ, на слова "ты пиздишь", лол?
структура процедуры
начало
проверка предусловий
действие+проверка промежуточных условий
проверка постусловий
возврат
в твоём случае получаем
начало
проверка предусловий
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
действие+проверка промежуточных условий
проверка постусловий
возврат
что? вообще-то я перестал следить за своим тоном из-за вот этого твоего сообщения #ogeets/5 . иначе слова "пиздишь", "долбоёб" и прочие просто так не прозвучали бы в твою сторону.
/5 твоё
я сослался на другой топик, вообще-то
ну вот я тебе о том и говорю, что возьми простыню, которой ты назвал "в твоём случае получаем", и замени слово "возврат" на слово "в переменную-аккумулятор возвращаемого значения помещаем возвращаемое значение". получится, что вместо возврата мы получим ret_val = 123, плюс необходимость пройти в конец простыни и убедиться, что этот самый ret_val никак не модифицируется более.
"действия+проверка промежуточных условий" полностью покрывает всю простыню, кроме проверки постусловий и возврата.
надеюсь никто не спорит, что проверять постусловия надо?
в данном случае не нужно проверять постусловия перед каждым возвратом.
а ошибка непроинициализированной переменной результата это уже другой тип ошибок, и не думаю, что куча ретурнов это хороший способ избежать ошибки.
то есть ты считаешь что вопрос "а что, надо доказывать?" он вообще адекватный?
естественно, речь идёт о ситуации, где нет необходимости проверять пост-условия. иначе причиной избавления от множественных return'ов может будет банальное избавление от копипасты.
в том отношении, в котором я его употребил — да. иначе я бы этого не делал. спрашивал про необходимость доказывать в том смысле, что, как мне кажется, необходимо доказывать именно использование одного return'а (вместо множества), т.к. множественный return — вполне легальное средство языка.
к вопросу о свободе действий.
это примерно как стрельба по людям, ведь реальность не мешает стрелять в людей, и только другие люди, осознав опасность этого, решают ввести искусственные ограничения на стрельбу, которые выставляют условия для этого.
поэтому я не говорю что ретурны это плохо или хорошо, я описываю возможные ошибки и средства их устранения, предотвращения.
да, я понял. а я описываю другие, точно так же возможные ошибки, возникающие при твоих "ограничениях", и о том, что замена множественного return'а на один делает только хуже читаемость кода.
вот я и пытаюсь во всю понять, от каких же конкретно ошибок нас избавляет замена множественного return'а на единичный. чувствую, скоро придется тратить время и код писать настоящий, иначе ну никак не вижу этих преимуществ.
кроме пост-условий, о которых (как мне было очевидно) речь не идёт. если нужны пост-условия именно в рамках этой же функции (а не функции-обёртки над этой), то я согласен, множественные return'ы плохо — но по причине копипасты, естественно.
Попробуй в своей основной деятельности перейти на способ построения алгоритмов без кучи ретурнов (и аналогов, типа выхода из середины цикла). ведь все знают, как НЕ юзать все эти недо-гото, пусть даже они и более предсказумы. А искусственные примеры всегда будут неполны, да и вот так сразу не поймёшь, что будет показательным в данной ситуации.
Тут есть конечно, доля субъективного восприятия, ну впрочем как и у всех людей. Надо понимать, что отделить разумное от животного довольно трудно, и на самом деле может оказаться так, что уверенность в правильности одного из методов это тупо нежелание менять привычный и ненапрягающий рабочий процесс.
Я вот не утверждаю, что способ описаный в треде стопудов верный, и понятно, что с переменной результата (да и нет гарантии, нужна ли она будет, ведь изначально функция строилась под использование ретурнов), придут другие типы ошибок, но вот оценку СТРАШНОСТИ и вообще, сравнение результатов того или иного применённого метода, я щитаю, не получится выполнить настолько просто и быстро, чтобы вот так за один день решить, что тебе и с ретурнами неплохо живётся.
С другой стороны, избегание ошибок чисто за счёт ограничения свободы ничуть не более напрягает, чем слежение разума за корректностью свободного кода. По крайней мере ретурны меня не беспокоят, потому что их тупо нет.
всё, что я хочу понять — от какого же типа ошибок спасает избегание множественных ретурнов. ты вот употребил "нарушение структуры тела процедуры". я так понял, что под структурой тела процедуры ты имеешь в виду
структура процедуры
начало
проверка предусловий
действие+проверка промежуточных условий
проверка постусловий
возврат
если это считать за структуру процедуры, то конечно ты прав и её структура нарушается. но тогда непонятно зачем создатели языка впринципе сделали return, а не, скажем, "возврат == последнее выражение". мне кажется, что return в любом месте процедуры по мнению авторов ЯП как раз входят в её структуру, а искуственное избавление — лишь имитация этих множественных return'ов при помощи вспомагательных переменных ("руками").