Comments 14
спасибо, я с вами согласен, но, если смотреть на код который вы показываете отступов должно быть больше, если вам нужны примеры посмотрите на код, который легко читается в исходниках Юникс версии 6, достаточно пары файлов посмотреть и вы поймёте что значит читаемый код, по вопросу разработки окон, эвристически сам тоже понял, что эта часть требует проф. скиллов, потомучто всё надо прорабатывать помимо читаемоти почти до идеала
Хотелось бы подтверждение теории разбитых окон для кода, в цифрах. А то всё на словах...
Если есть статистика то можно принимать решения, а так это за все хорошее, против всего плохого, но приоритет нулевой
Не только вам кажется, что теория разбитых окон применима к разработке ПО. В довольно уже старой, но всё равно отличной книге «Программист-прагматик. Путь от подмастерья к мастеру» Эндрю Ханта и Дэвида Томаса, об этом уже давно написано.
В применении к статическим анализаторам кода, это выливается в простое правило: не стоит отключать диагностики в угоду плохому коду, даже если сроки поджимают.
Спасибо за комментарий! Про "Программист-прагматик" действительно упустил. Книга давно стоит на полке и ждёт, никак не соберусь с мыслями, чтобы посвятить ей достаточно времени)
Насчёт подхода к статическому анализу дополню, что не стоит отключать диагностики просто для того, чтобы спрятать то, что он находит. Если вы хотите выключить диагностику на этапе внедрения, это вполне может быть оправдано. Например, нет смысла включать диагностические правила стандартов MISRA, если вы не разрабатываете ПО в соответствии с этими стандартами :)
Проблема использования огромных switch вместо полиморфизма с точки зрения чистого кода состоит в том, что в определённый момент поддерживать огромные switch или if выражения становится трудной задачей.
... Прочитать можно по этой ссылке.
По ссылке нашел пересказ спора, в котором не было победителя. Однако оба оппонента на выбранной модельной задаче пришли к решениям примерно одинаковой сложности (для понимания и поддержки кода). Дело не в огромности switch'а.
То есть если бы не было огромного switch, был бы столь же огромный набор классов. С точки зрения сложности код-ревью на этапе появления и усилий на этапе поддержки - оба подхода "не айс".
Я было думал написать, что юнит-тест должен быть построен так, чтобы отловить эту ошибку (для типа UInt64 используется метод ToInt64), однако и юнит-тест будет страдать от тех же проблем: на этапе копи-пасты легко перепутать что с чем должно совпасть при проверке.
До обнаружения этой проблемы написать правильный юнит-тест, который смог бы ее обнаружить (конкретно в этом случае) - маловероятно.
Короче для этого кейса вы смело могли бы использовать слоган "вы не нашли бы эту багу без PVS".
а как избавится от больших свитчев ? https://dpaste.com/FXXMXGZ6L
https://refactoring.guru/ru/smells/switch-statements
Конкретное решение нужно выбирать по месту и потребностями и конечно у всех есть плюсы и минусы, вопрос лишь что больше подойдёт (важно вам), иногда и свитч проходит лучше, но с этим мало/редко соглашаются (по объективным причинам)
Я еще хочу спросить автора по кейсу
Предупреждение PVS-Studio:
V3139 Two or more case-branches perform the same actions.
Если вы обратили внимание, то для типа UInt64 используется метод ToInt64. Вероятнее всего, это copy-paste ошибка.
А если бы это был набор классов, какая вероятность найти ошибку?
P.S. ни в коем случае не фанат свитчей, но тут пример кажется притянутым.
Спасибо за комментарий!
В статье по той ссылке действительно был пересказ спора с моими комментариями, но также была и вторая часть с, что называется, размышлениями на тему.
Насчёт "огромности" switch согласен, что с точки зрения code review иерархия классов будет не лучшей альтернативой. Но мне всё же кажется, что в процессе написания кода при правильной декомпозиции можно просто глазами заметить ошибку. Но это, полагаю, imho
Грязный код — надёжное хранилище ошибок. Теория разбитых окон