20.12.2023, 06:40
Это они еще 1С не видели..
Но слышали, поэтому и ввели санкции.
флаттер
![void lex_stt_op(uint8_t c)
{
»
»
//printf(%s\n",op[*mem_sstack].name); switch(*(uint8_t*)mem_sstack)
{
»
»
case OPUNDEF: swltch(c)
» {
case :
*( uint8_t*)mem_sstack return; case '- ' :
*( uint8_t*)mem_sstack return; case :
*(uint8_t*)mem_sstack return; case '/' :
*(](https://img2.joyreactor.cc/pics/comment/it-юмор-geek-5107579.png "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор")
Лексический анализатор, из которого скриншот, один занимает 520 строк кода. Во всех файлах уже под 2000. Держу код достаточно простой, у меня проблем с навигацией не возникает.
Если я вытащу вложенные свитч-кейсы в функции, получу 10+ маленьких функций, которые не имеют смысла сами по себе (по этому будут иметь сложные, маловнятные названия) и увеличу код ещё на 30+ строк просто за счёт объявления этих функций. Я не думаю, что это положительно скажется на читабельности кода.
Глубокая вложенность - это беда, я уже давно своими мозгами пришел к обоим методам, предложенным в видео, Но устанавливать нормативы вложенности, это тоже бред. Всегда найдётся ситуация, в которой глубокая вложенность будет лучшим решением с точки зрения читабельности.
Если я вытащу вложенные свитч-кейсы в функции, получу 10+ маленьких функций, которые не имеют смысла сами по себе (по этому будут иметь сложные, маловнятные названия) и увеличу код ещё на 30+ строк просто за счёт объявления этих функций. Я не думаю, что это положительно скажется на читабельности кода.
Глубокая вложенность - это беда, я уже давно своими мозгами пришел к обоим методам, предложенным в видео, Но устанавливать нормативы вложенности, это тоже бред. Всегда найдётся ситуация, в которой глубокая вложенность будет лучшим решением с точки зрения читабельности.
Можно, но если честно жаба душит - таблички будут иметь больий футпринт в памяти и чем ветвления switch'ей из-за того что символы операторов идут не подряд. А проект пишется так, что бы можно было на МК использовать. Кроме того всё равно будет куча if после табличек, потому что там не в каждом case код вида A = const; retern;
Да и если честно, на стадии разработки вот этот вот массив условий легче править, чем таблички.
Есть мысли уйти от этого монстра либо к поиску по массиву (O(log n) - O(n) вместо O(1)), либо к генерируемым исходникам, но пока что это не горит. Тем более что конкретно этот кусок кода уже работает, а многое из того, что хотелось бы - ещё только в планах.
Да и если честно, на стадии разработки вот этот вот массив условий легче править, чем таблички.
Есть мысли уйти от этого монстра либо к поиску по массиву (O(log n) - O(n) вместо O(1)), либо к генерируемым исходникам, но пока что это не горит. Тем более что конкретно этот кусок кода уже работает, а многое из того, что хотелось бы - ещё только в планах.
На самом деле, it depends.
Бывают очень длинные свитчи, которые обрабатывают занудную stateful хуйню по доке, и внутри обработки где-то пару операторов, где-то ещё свитчи внутри.
И, как правило, как раз такие вещи обычно в критических по перформансу местах.
Так вот, как читающий часто такой код с докой под рукой, ответственно заявляю:
Нахуй выделение в методы(кроме особых случаев, где уж слишком отдельная обработка).
Нахуй выделение значений в ёбанные константы. Оставьте, сука, меджик намберс и чарс прямо как они описаны в протоколе, я ебал по коду носиться в определение констант хуй знает где, которые всё равно один раз используются.
Так что твоё высказывание про поддерживаемость лично мной не подтверждается. Строго говоря, линейный код читать проще, чем винегрет из миллиона методов, в которых хуй проссышь, и не видно всей картины.
Бывают очень длинные свитчи, которые обрабатывают занудную stateful хуйню по доке, и внутри обработки где-то пару операторов, где-то ещё свитчи внутри.
И, как правило, как раз такие вещи обычно в критических по перформансу местах.
Так вот, как читающий часто такой код с докой под рукой, ответственно заявляю:
Нахуй выделение в методы(кроме особых случаев, где уж слишком отдельная обработка).
Нахуй выделение значений в ёбанные константы. Оставьте, сука, меджик намберс и чарс прямо как они описаны в протоколе, я ебал по коду носиться в определение констант хуй знает где, которые всё равно один раз используются.
Так что твоё высказывание про поддерживаемость лично мной не подтверждается. Строго говоря, линейный код читать проще, чем винегрет из миллиона методов, в которых хуй проссышь, и не видно всей картины.
Дока, ха. Дока это удовольствие дорогое, она маоо где есть а еще меньше где она поддерживается в актуальном состоянии. Потому что дока - это дорого. Дороже юнит - тестов. Я сам не любитель разносить код по методам чисто для красоты, но если я вижу хотя б 2 места с общим кодом - я его выношу.
fast-fail - просто маст хев. Всегда
А по константам я категорически не согласен. Они во первых говорят как связан код по смыслу, ну и просто позволяют не бегать по 20 файлам менять значение
А что до конста
fast-fail - просто маст хев. Всегда
А по константам я категорически не согласен. Они во первых говорят как связан код по смыслу, ну и просто позволяют не бегать по 20 файлам менять значение
А что до конста
Вот юнит-тесты это удовольствие дорогое в некотором типе кода. В котором, в частности, всё на скорость, потому массивный реюз всего(да, выделять память бывает дорого, точнее, дорого её освобождать и менеджить) и всё, что можно - стейтфул. Не от хорошей жизни - чуть в менее стеснённых условиях лучше без вот этого всего. Но когда у тебя на обработку реквеста и выдачу ответа до 700 наносекунд, а превышение за микросекунду(не милли! милли это 1000 микро) - это логируемый ворнинг и прод ишью, который надо фиксить...
Потому доки. Без них смерть.
>fast-fail - просто маст хев. Всегда
Не всегда(я вообще против абсолютизма, всегда зависит от ситуации - это единственное допустимое "всегда"), но чаще всего да. По крайней мере на уровне логической единицы(но возможен фаллбек с полным реинитом с нуля).
>А по константам я категорически не согласен. Они во первых говорят как связан код по смыслу, ну и просто позволяют не бегать по 20 файлам менять значение
Если у тебя реализация парсинга протокола, то используется оно один раз.
И дока выглядит как-то так:
msg_type(byte)
's':
sync message, structure: ....
'S':
sequence, ...
'L':
login request, ...
'p':
price() change, ...
...
Так вот. Эти байтики - однозначные идентификаторы, и мне в хуй не всралось, ища реакцию на месседж с типом 'K' искать, как именно тот, кто писал, назвал константу. Мне нужен месседж 'K', я ищу его именно по этой метке. А не по названию. А так мне надо сначала пойти в определение констант, которые отделены от реакций, узнать, как именно предыдущий программист назвал константу со значением 'K', и потом пиздовать назад в код искать использование этой константы.
Потому доки. Без них смерть.
>fast-fail - просто маст хев. Всегда
Не всегда(я вообще против абсолютизма, всегда зависит от ситуации - это единственное допустимое "всегда"), но чаще всего да. По крайней мере на уровне логической единицы(но возможен фаллбек с полным реинитом с нуля).
>А по константам я категорически не согласен. Они во первых говорят как связан код по смыслу, ну и просто позволяют не бегать по 20 файлам менять значение
Если у тебя реализация парсинга протокола, то используется оно один раз.
И дока выглядит как-то так:
msg_type(byte)
's':
sync message, structure: ....
'S':
sequence, ...
'L':
login request, ...
'p':
price() change, ...
...
Так вот. Эти байтики - однозначные идентификаторы, и мне в хуй не всралось, ища реакцию на месседж с типом 'K' искать, как именно тот, кто писал, назвал константу. Мне нужен месседж 'K', я ищу его именно по этой метке. А не по названию. А так мне надо сначала пойти в определение констант, которые отделены от реакций, узнать, как именно предыдущий программист назвал константу со значением 'K', и потом пиздовать назад в код искать использование этой константы.
если он твой лид, то да, вне закона.
вообще, считается что чем меньше ветвлений тем лучше для чтения кода. Но в демонстрационных примерах параметров редко много. а в жизни бывают какие-нибудь бизнес сущности типа сделок со 100500 условий которые еще и не надо учитывать если Сатурн в Водолее.
с другой стороны, иногда люди подходят к вопросу со смертельной серьезностью, и если можно выражение написать в одну абсолютно не читаемую строку - они ее напишут, и будут считать любой if как пример плохого кода
вообще, считается что чем меньше ветвлений тем лучше для чтения кода. Но в демонстрационных примерах параметров редко много. а в жизни бывают какие-нибудь бизнес сущности типа сделок со 100500 условий которые еще и не надо учитывать если Сатурн в Водолее.
с другой стороны, иногда люди подходят к вопросу со смертельной серьезностью, и если можно выражение написать в одну абсолютно не читаемую строку - они ее напишут, и будут считать любой if как пример плохого кода
"редко много" сначала сбило с толку
Так и я про то же - ограничивать уровень вложенности - это бред. Снизить читаемость кода можно как бесконечными вложениями, так и растягивая код в мешанину вызовов функций только что бы снизить уровень вложенности там, где этого делать не надо.
Знаете что было самым нечитаемым из всех исходников, которые я читал в жизни? Исходник хренового led-куба из журнала радио №12 от 2015 года.
И дело совсем не в том, что там код на ассемблере. Я асм для пиков хорошо знаю.
Он абсолютно линеен и выполнен в стиле "включиль слой №", "включить светодиды №№", задержка, "включить светодиды №№", задержка ...
Зато никакой вложенности.
Знаете что было самым нечитаемым из всех исходников, которые я читал в жизни? Исходник хренового led-куба из журнала радио №12 от 2015 года.
И дело совсем не в том, что там код на ассемблере. Я асм для пиков хорошо знаю.
Он абсолютно линеен и выполнен в стиле "включиль слой №", "включить светодиды №№", задержка, "включить светодиды №№", задержка ...
Зато никакой вложенности.
по опыту я могу сказать так - главное чтобы код был тебе понятен после того, как ты его через год откроешь, чтобы чтото дописать или что-то исправить. Поэтому я никогда не парюсь изза IF или SWITCH/CASE, потому что мне прежде всего так нагляднее.
Но иногда жизнь пересекала меня с протекционистами разного уровня, в том числе и теми, что любили все условия сложить в одну строку. И приходилось соответствовать, иногда не очень удачно. Нужно сказать в программировании как-то чаще всего встречаются единственные и не непогрешимые боги, с которыми проще принять их религию чем каждый день сраться. ну то есть, сраться скорее всего все равно прийдется, нохотя бы на один вопрос будет меньше
Но иногда жизнь пересекала меня с протекционистами разного уровня, в том числе и теми, что любили все условия сложить в одну строку. И приходилось соответствовать, иногда не очень удачно. Нужно сказать в программировании как-то чаще всего встречаются единственные и не непогрешимые боги, с которыми проще принять их религию чем каждый день сраться. ну то есть, сраться скорее всего все равно прийдется, нохотя бы на один вопрос будет меньше
Чтобы написать коммент, необходимо залогиниться
