LINUX.ORG.RU

Чем плохо много return?

 ,


0

3

В линтерах во многих языках программирования есть такая проверка: https://docs.astral.sh/ruff/rules/too-many-return-statements/

По ссылке приведён тривиальный пример, где достаточно сопоставления по ключу.

В общем случае код выглядит примерно как:

def f(x):
  if cond1(x):
    return res1
  y = process1(x);
  if cond2(y):
    return res2
  if cond3(y):
    return res3
  z = process2(x, y)
  if cond4(x,y,z):
    return res4
  if cond5(x,y,z):
    return res5
  ...  

после убирания return получается что-то вроде

def f(x):
  done = False 
  if cond1(x):
    res = res1
    done = True
  if not done:
    y = process1(x);
  if not done and cond2(y):
    res = res2
    done = True
  if not done and cond3(y):
    res = res3
    done = True
  if not done:
    z = process2(x, y)
  if not done and cond4(x,y,z):
    res = res4
    done = True
  if not done and cond5(x,y,z):
    res = res5
    done = True
  ...
  return res  

Второй вариант действительно легче читается или я неправильно преобразовал первый во второй?

UPD: С учётом наличия elif

def f(x):
  done = False 
  if cond1(x):
    res = res1
    done = True
  if not done:
    y = process1(x);
    if cond2(y):
      res = res2
      done = True
    elif cond3(y):
      res = res3
      done = True
  if not done:
    z = process2(x, y)
    if cond4(x,y,z):
      res = res4
      done = True
    elif cond5(x,y,z):
      res = res5
      done = True
  ...
  return res  

Вот это читается легче, чем первый вариант?

★★★★★

Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от oxo

Хороший это который за свой жизненный цикл принесёт денег побольше, а затратит поменьше.

Я с вами в целом согласен, но с точки зрения энтерпрайза (насколько я могу судить со своего шестка) деньги — не главное. Т.е. они конечно должны быть, ради того всё и затевалось, но главным критерием оценки являются риски. Риски должны быть просчитаны и оценены. Поэтому между командой гениев, которые быстро напишут хороший продукт (но может в процессе разругаются и ничего вообще не выйдет) и толпой коекакеров которые с заданной скоростью будут проедать бюджет и двигать ticket’ы по scrum’овой доске спринт за спринтом — всегда выберут второе.

Я понимаю менеджеров, которые не желают ставить свою жопу на успех проекта. Не осуждаю. Но именно по этому ИТ и пребывают в таком мизерабельном состоянии.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Вот это более логично.

«Хороший» здесь тот, который можно быстро починить не очень квалифицированным сотрудником. В этом смысле старый УАЗик лучше нового Мерседеса.

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

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Очень ограниченно. Обычно только на идентичное из-за износа. Поставь коробку передач от мерседеса на вольво.

Если уж использовать автомобильные аналогии, то свои абстракции есть и в автомире. В рамках одной платформы создают и фургоны, и хэтчбэки. И это круто. Но не бесплатно. На разработку MQB, для примера, Volkswagen потратил порядка 8 миллиардов евро.

ugoday ★★★★★
()
Ответ на: комментарий от oxo

Так и с кодом то же самое. Вместо того, чтобы рискнуть и написать идеальное решение под данную задачу, всегда выберут начать стандартно-типовой проект который будет более-менее работать, применить обычные шаблоны проектирования, просто потому, что их всегда применяют, заложить пути расширения, из которых 90% не будут востребованы никогда и т.п. Продукт будет работать и ни одного менеджера не уволили, а сеньора не пожурили за внедрение ещё одного слоя абстракций. А пользователи — пользователи потерпят. Я, вот, в SAP работаю. У нас куча заказчиков и хрен они куда денутся с подводной лодки. Так и чего ради них напрягаться?

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

Правильно так - «коекакеры должны писать код».

Sorry.
У @oxo всё правильно сказано.

Но что же поделаешь. такова наша селяви.
А вот насчёт ошибок в коде …
ОКЕАН!

Посмотрите issue любого проекта.
Так и живём …

anonymous
()
Ответ на: комментарий от oxo

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

ugoday ★★★★★
()
Ответ на: комментарий от oxo

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

monk ★★★★★
() автор топика
Ответ на: комментарий от oxo

Крупный работающий проект по-другому не сделать. Хоть АЭС, хоть космос - там сплошной waterfall.

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

monk ★★★★★
() автор топика
Ответ на: комментарий от oxo

Поправлюсь, гарантировать качество крупного проекта по-другому нельзя.

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

Проблема, если финансирования или времени «чуть-чуть» не хватило. Тогда в случае водопада результата нет, как нет автомобиля или завода, если на него денег не хватило. В случае других методик есть прототип, который как-то криво и с ошибками, но можно использовать, как дом, в котором недоделали ремонт. Зато при водопадной модели и денег и времени изначально требуется меньше, так как нет необходимости закладывать в каждый модуль слой абстракции для произвольных проектных изменений.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

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

Да и waterfall никак не гарантирует. Да и какая разница какое качество – главное сколько мы заработаем и как долго мы будем зарабатывать.

oxo
()
Ответ на: комментарий от oxo

уёдём в емперии

вопрос когда и как сверхкомпилировать

если ваще заигнорить перевод в нечеловеческую машину то можно налепить в подходящем(уж за несколько веков всяко есть подходящий жаргон в целевой прикладной области) dsl что нужно реальным консумерам и телемаркет

а вот двигло не беспокоя санитаров и консумеров можно уж на хоть субкварковых квантах были ли бы бойцы-кодеры

а инче не помятно что телега а что лощах - то что менежулью нужны некомпетентные сеньёры али наобоврот

qulinxao3 ★☆
()
Ответ на: комментарий от oxo

Гарантирует. По нему или всё закончилось успешно с заданным качеством. Или закончилось провалом без результата, так как денег не хватило. Создание сырого прототипа планом не предусмотрено.

monk ★★★★★
() автор топика
Ответ на: комментарий от oxo

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

к слову об хрематистике

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

Гарантирует

Удовлетворение FR/NFR может и да, но не качество.

По нему или всё закончилось успешно с заданным качеством. Или закончилось провалом без результата, так как денег не хватило.

Отличная антиреклама 👍

oxo
()
Последнее исправление: oxo (всего исправлений: 1)
Ответ на: комментарий от oxo

Удовлетворение FR/NFR может и да, но не качество.

Так качество в них и прописывается.

Отличная антиреклама 👍

Как лучше, когда программа при ошибке падает, а не творит undefined behaviour, так лучше, когда проект не производит ничего, чем производит глючное нечто, которое заказчик будет использовать, так как «деньги же потрачены».

Впрочем, нынче и микросервисы с Си++ в моде, так что программа может достаточно долго агонизировать и творить что попало перед тем, как окончательно выключиться. Счастье лишь в том, что весь этот мусор ничем критичным не управляет.

monk ★★★★★
() автор топика
Ответ на: комментарий от oxo

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

anonymous
()
Ответ на: комментарий от oxo

А этика-то тут при чём?

Лучше конечно когда хоть что-то как-то работает, чем когда нет ничего

Зависит от области. Если это компьютерная игра или видеопроигрыватель, то да. Если это учётная система, то спасут резервные копии, тоже скорее да, чем нет. Если же это любая система управления реальным миром от умного дома до автомобиля, то лучше когда нет ничего, чем автоматика, приводящая к аварии.

monk ★★★★★
() автор топика
Ответ на: комментарий от oxo

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

anonymous
()
Ответ на: комментарий от oxo

Нет. Она проиграла в отсутствии конкуренции при одновременном проклятье ресурсов, как и многие другие глобальные отрасли, например, самолёты (из игроков в мире сейчас только боинг и аирбас и им доступно 99% поставщиков компонентов со всего мира, в Северной Корее нет поставщиков деталей для самолётов, а в РФ и Иране их мало или они завалены внутренними заказами).

anonymous
()
Ответ на: комментарий от oxo

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

anonymous
()
Ответ на: комментарий от oxo

В интернете достаточно информации про что угодно. И про недостатки водопада, и про недостатки agile, и даже про кыштымских карликов есть. А по факту получается, что если добавлять всё больше слоёв абстракции и точек расширений, где поведение можно подправить каким-нибудь хитрым модулем, мы в эти модули логику и переносим. А сама программа становится таким вот интерпретатором странненького языка. Тогда почему бы уж сразу не начать писать на Common Lisp’е? Он хотя бы стандартизированный.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

oxo
()
Ответ на: комментарий от oxo

Неа.

С космосом и прочим реальне h.tecом автоматизация продолжает рогоизобилить, а вот с чем айти заведомо не подходящий инструмент так устранением «оппортунизма»

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

Русский письменный 140мегачел и больше

куда важнее знание рядом-лежащих штук: например в моей специфике posgres, kube, kafka – а уж чем перекладывать джейсонки дело десятое

oxo
()
Ответ на: комментарий от qulinxao3

культ шаблонов(патернов) как более экономически выгодное на краткосроке чем качественно подготовленные кодеры

Кодеры и так подготовлены, но область разработки диктует свои правила. Что для джависта естественно, то для эмбедед-программиста - жуткая дичь и наоборот. У программистов, обеспечивающих работу банков, торговцев и других подобных областей, было и есть больше денег - вот у них и получается громче пиарить свои подходы. Но времена меняются.

Kogrom
()
Ответ на: комментарий от Kogrom

nine молотов

куча куч паттернов(не все но многие) просто мало нужны ежель кодеры полноцено отдупляют концепцию индексируемой памяти т.е. обычные массивы

по сути язык с массивом экивалентен гомоиконному лиспу со сборщиком муссора

но низкоквалифицированным кодерам дешевле(нанимателям в целом) вдолбить мантры Читого_кода Мартина(али ёщё какого гуро)(при том что сам Мартин на асме вполне вменяемый код лабал во временна оные) - ибо ща компы на бы(дл|т)овых задачах буквально пушкой по воробьям - т.е. алго-сложность мало важна - достаточно что бы работало ибо сам факт автоматизации переводит время решения с маштаба человека(часы и прочая) в маштаб машины - секунды(и доли её)

так что шаблоны шаблонов позволяют исчерпать дистанцию с долей секунд до человеческих маштабов - часов

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

кому не те

community тех, кто хочет странного: вино LFS и бутылки дистрибутивов пакетных менеждеров слакодебиана (и метадистрибутивов «коммунити – кому нити пучка пряжи с ебилдами»)

все хотят вина, но не хотят или не умеют его готовить.

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

то же самое и LFS: «вступай и конпелируй» – будет ровно то, что ты сам в рецепт положил. что вкусно именно тебе и невозможно испортить (ибо ты не конпелировал туда системду и всякое ненужно)

не настоящий сварщик джедай не настолько генри хардкор петро шолти. он таки идет в гомозин дистрибутивов и закупается стеклотарой – вино для него ценно не само по себе, а только тем что оно уже есть готовое, его не нужно готовить самому когда уже есть.

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

с одной стороны, вино и бутылки. все хотят вина, но по своим особенным рецептам. и не хотят бодяжить купажи и пробовать и чтобы сбродило да не в уксусин.

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

идеальное вино – достижимо ли оно в безбутылочной технологии сферического вина в вакууме по канонiчным рецептам твоего дедушки? и когда же наконец, можно будет успокоиться пробовать – и начать отмечать.

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

… а если тебе нужно вино, но не нужна стеклотара? тогда приходится бодяжить самому.

можно собрать самому идеальное вино, но готовить его несколько недель, собирая из исходников.

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

…. но есть ли у этого духа вина свое идеальное комуните или это они – кому не те? и кто оне – идеальные те ???

покупателям стеклотары – проще закатить совместную вечеринку. оно уже сразу годное и готовое, а не через две недели, когда техпроцесс невозбранно конпелять

… а потом на вторую производную пьянки – стеклотару сдать, повторить раз и ещё раз.

можнозделать идеальное «вино без бутылки» – но как закатить вечеринку на вторую производную идеальной пьянки ???

вот в чем сермяжная правда вопросов хренотистики современной ойти-технологии.

anonymous
()
Ответ на: комментарий от qulinxao3

как результат тотальное неграмотное программирование отсюда и культ шаблонов(патернов) как более экономически выгодное на краткосроке чем качественно подготовленные кодеры

больше шаблонов богу шаблонов как каргокульти современной хренотистики краткосрока коекаеров заместо исконно посконной долгосрочной економики.

проблемы верволка в средней полосе и шерифы с индейцами.

настоящему индейцу завсегда и везде.

anonymous
()
Ответ на: комментарий от qulinxao3

… готов ли ты для чайной церемонии собрать свой пуэр на склоне холма в лунную ночь, написав екёбану настоящей тушью и каллиграфией на веньян – или тупо снова идешь в гомозин закупиться чаем в пакетиках с катаканою, а не хираганою – на байцзи?

.. ты так всю чайную церемонию на нет сведешь, отрок.

anonymous
()
Ответ на: комментарий от qulinxao3

мантры Читого_кода Мартина(али ёщё какого гуро)(при том что сам Мартин на асме вполне вменяемый код лабал во временна оные)

дедушка мартин хороший был вождь

а все остальные такое гуро

читый читают на не чисто вот такие читаки

anonymous
()