One morning you wake up find out you have access to God’s developer console. What’s the first thing you do with this power?
Discussion
♦ 154 + W 479 & Share
^ BEST COMMENTS ▼
I like forks • 5h
hehe3301 • 7h
sudo rm -rf oceans/*/contents/
*.plástic
sudo rm -rf people/*/*.cáncer sudo rm -rf v
Чёт он как то слишком нежный для программиста.
Если я вытащу вложенные свитч-кейсы в функции, получу 10+ маленьких функций, которые не имеют смысла сами по себе (по этому будут иметь сложные, маловнятные названия) и увеличу код ещё на 30+ строк просто за счёт объявления этих функций. Я не думаю, что это положительно скажется на читабельности кода.
Глубокая вложенность - это беда, я уже давно своими мозгами пришел к обоим методам, предложенным в видео, Но устанавливать нормативы вложенности, это тоже бред. Всегда найдётся ситуация, в которой глубокая вложенность будет лучшим решением с точки зрения читабельности.
Да и если честно, на стадии разработки вот этот вот массив условий легче править, чем таблички.
Есть мысли уйти от этого монстра либо к поиску по массиву (O(log n) - O(n) вместо O(1)), либо к генерируемым исходникам, но пока что это не горит. Тем более что конкретно этот кусок кода уже работает, а многое из того, что хотелось бы - ещё только в планах.
Бывают очень длинные свитчи, которые обрабатывают занудную stateful хуйню по доке, и внутри обработки где-то пару операторов, где-то ещё свитчи внутри.
И, как правило, как раз такие вещи обычно в критических по перформансу местах.
Так вот, как читающий часто такой код с докой под рукой, ответственно заявляю:
Нахуй выделение в методы(кроме особых случаев, где уж слишком отдельная обработка).
Нахуй выделение значений в ёбанные константы. Оставьте, сука, меджик намберс и чарс прямо как они описаны в протоколе, я ебал по коду носиться в определение констант хуй знает где, которые всё равно один раз используются.
Так что твоё высказывание про поддерживаемость лично мной не подтверждается. Строго говоря, линейный код читать проще, чем винегрет из миллиона методов, в которых хуй проссышь, и не видно всей картины.
fast-fail - просто маст хев. Всегда
А по константам я категорически не согласен. Они во первых говорят как связан код по смыслу, ну и просто позволяют не бегать по 20 файлам менять значение
А что до конста
Потому доки. Без них смерть.
>fast-fail - просто маст хев. Всегда
Не всегда(я вообще против абсолютизма, всегда зависит от ситуации - это единственное допустимое "всегда"), но чаще всего да. По крайней мере на уровне логической единицы(но возможен фаллбек с полным реинитом с нуля).
>А по константам я категорически не согласен. Они во первых говорят как связан код по смыслу, ну и просто позволяют не бегать по 20 файлам менять значение
Если у тебя реализация парсинга протокола, то используется оно один раз.
И дока выглядит как-то так:
msg_type(byte)
's':
sync message, structure: ....
'S':
sequence, ...
'L':
login request, ...
'p':
price() change, ...
...
Так вот. Эти байтики - однозначные идентификаторы, и мне в хуй не всралось, ища реакцию на месседж с типом 'K' искать, как именно тот, кто писал, назвал константу. Мне нужен месседж 'K', я ищу его именно по этой метке. А не по названию. А так мне надо сначала пойти в определение констант, которые отделены от реакций, узнать, как именно предыдущий программист назвал константу со значением 'K', и потом пиздовать назад в код искать использование этой константы.
Если реагирование - декларативно мапу функций-реакций, и процедура перехода.
вообще, считается что чем меньше ветвлений тем лучше для чтения кода. Но в демонстрационных примерах параметров редко много. а в жизни бывают какие-нибудь бизнес сущности типа сделок со 100500 условий которые еще и не надо учитывать если Сатурн в Водолее.
с другой стороны, иногда люди подходят к вопросу со смертельной серьезностью, и если можно выражение написать в одну абсолютно не читаемую строку - они ее напишут, и будут считать любой if как пример плохого кода
Знаете что было самым нечитаемым из всех исходников, которые я читал в жизни? Исходник хренового led-куба из журнала радио №12 от 2015 года.
И дело совсем не в том, что там код на ассемблере. Я асм для пиков хорошо знаю.
Он абсолютно линеен и выполнен в стиле "включиль слой №", "включить светодиды №№", задержка, "включить светодиды №№", задержка ...
Зато никакой вложенности.
Но иногда жизнь пересекала меня с протекционистами разного уровня, в том числе и теми, что любили все условия сложить в одну строку. И приходилось соответствовать, иногда не очень удачно. Нужно сказать в программировании как-то чаще всего встречаются единственные и не непогрешимые боги, с которыми проще принять их религию чем каждый день сраться. ну то есть, сраться скорее всего все равно прийдется, нохотя бы на один вопрос будет меньше