Почитала тут статеечку.
Да я матерая уголовница!
По крайней мере, по статье 1, да еще по сговору с группой лиц...
Пора сушить сухари.

Цитирую:

Уголовный кодекс разработчика

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

Я сейчас не говорю про «Административный кодекс», куда я как раз и отношу неправильное применение шаблонов, неиспользование тестов, неоптимизированный код, даже харкодинг каких-нибудь настроек и «магические числа» (хотя уже на грани). В этих случаях разная правоприменительная практика. Например оптимизированный код часто сложнее для понимания, чем неоптимизированный. Неоптимальный алгоритм зачастую легче воспринимается при чтении кода, а ведь разработчик 95% времени читает свой или чужой код и только 5% пишет. Или если вы пишите скрипт для друга забесплатно, побыстрее и заходкодили пару настроек, вы скорее всего правильно поступили. Решив, что интеграция туда логики извлечения настроек (и ее тестирования) из отдельных конфигов потребует намного большего времени, чем хардкод.

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

Статья 1. Закомментированный код

Как часто в проектах любого уровня это встречается, человек как бы говорит вам: я немного не уверен, может быть это еще понадобится, а может и нет я — хз, просто оставлю это пока тут. Типичный кодомусорщик. Есть даже целые закомменченные модули. Это опять же очень сильно влияет на читаемость кода, даже несмотря на то, что он идет другим цветом. Решение есть — просто удалить, и все. Но если вы такой хламушник, можете сделать в git спец ветку с названием например warehouse-of-old-trash и ваша душа будет спокойна.

Статья 2. Мертвый код. Мертвые зависимости

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

Сюда же можно добавить бестолковые заглушки. Например вчера увидел такое:

if (true){
someFunction();
}

На вопрос: «зачем ты это написал?», последовал ответ: «чтобы не забыть, что там должна быть проверка». Логично да? Ну напиши ты комментарий:

// нужно проверить на то-то,
someFunction();

Тоже не очень, но хоть понятно, что тебя не троллят т.к. данный проект скинулся мне со словами «очень хорошо написанный». Или посреди нормального рабочего кода идет Promise.delay(4000) — типа эмуляция какого-то долгого процесса, который еще не написан. Ну сделай ты моку, сразу будет понятно, что это класс фейковый и вопросов не будет.

Статья 3. Копипаст

Это не про бездумный копипаст со StackOverflow в проект, что тоже грех, а про то, что любой повторяющийся код содержащий более двух операторов должен быть убран в функцию. Это прям болезнь какая-то, в основном свойственная новичкам и любителям вышеприведенного копипаста с so. Лютое нежелание подумать над тем, что пишешь. Есть правда исключения. Например повторная логика, которую написал через какое-то время, забыв, что ее где-то уже писал или когда пишут разные люди, плохо читая остальной код. В любом случае при рефакторинге все должно убираться.

Статья 4. Гигантские методы

О да, этим страдают даже более-менее приличные проекты. По моему убеждению, метод должен быть не больше экрана компьютера (± усредненного конечно). Иногда на том же github сидишь разбираешься в чьем-то коде и понимаешь, что ты уже 3й экран пролистал, а идет та же самая функция, и мозг уже отказывается что-то понимать. Ну разбей ты по некоторым признакам код на функции, ну понятней в сто раз будет да еще и возможно переиспользовать какие-нибудь можно будет. Даже экран это много, в такой размер как исключения могут попадать функции с имплементацией математических выражений, где разбиение на мелкие части понимания может не добавить, иногда лучше чтобы все математическое выражение было в одной функции, но опять же не больше экрана.

Отягчающие обстоятельства

А. Множественность. Один раз, как говорится, можно. Ну например срочно нужно было отдать в релиз и быстро чего-нибудь там закомментили, отключили и тд. Но когда, это по всему проекту и тянется не один год, то это — вдвойне криминал.

Б. По предварительному сговору группой лиц. Если вы пишете один, или свой изолированный модуль это одно, но когда несколько человек отвечают за код содержащий выше описанное это — втройне криминал.

P.S. Чтобы не быть ханжой скажу, что у самого иногда в проектах проскакивают признаки состава преступлений из выше приведенных статей, но я никогда не назову такой свой код хорошим. Просто последнее время часто по работе вижу людей, «надувающих щеки» и говорящих, что вот у них код идеальный и 100% профессиональный. А при первом взгляде, когда еще не видно ошибок высокого уровня ( в паттернах там и тд ) вылезает вот это вот все.

©habrahabr.ru

tata
По моему убеждению, метод должен быть не больше экрана компьютера (± усредненного конечно).

Попадалась инфа, что то ли в НАСА, то ли в МО США - это стандарт, отступление от которого приравнивается к гос.измене

Там в комментах большой срач по поводу экстремизма заявления "любой повторяющийся код содержащий более двух операторов должен быть убран в функцию", заодно и с пунктом про "гигантские" модули. Программа тратящая 90% времени на вызов/возврат из функций (особенно если это не какой-нить си умеющий инлайнить методы) - это г*нокод. Даже если читать его "легко и приятно".
Ежели автор никогда не работал с тем же SQL, это не повод тыкать других "ущербностью" их кода. Да, на SQL вполне себе может быть и на 5 страниц ОДИН запрос - всего одна "команда".

tata
По крайней мере, по статье 1

Тут я согласен с тем, что эта проблема вызвана в первую очередь отсутствием вменяемой (удобной и понятной разработчику) системы контроля версия. Если все "варианты" можно разместить в разных ветках того же гита, и переключаться между ними за 5 секунд, то нужда в закомментированном коде, равно как и в "отключаемом" всякими if .F. отпадает... Без системы контроля версий - ну да, это проще чем вручную созданные архивы или просто кучи mylib.prg.v1

С уголовкой за форму изложения и оформления кода - это перебор конечно (попахивает бульдозерной выставкой при Хрущеве). Прога все-таки, прежде всего, должна работать (для чего есть тестировщики, есть приемка, есть опыт эксплуатации, доработки), а "красота" изложения (удобство восприятия дилетантами) - дело 10-е... Красота приятна, но не всегда получается сделать красиво "для всех", и время опять же... Это не фигурное катание, где 2 равноценные оценки - за техническое исполнение, и за "художку".

Кстати, 5-ти страничный SQL-запрос вполне "бывает", как и стольки же страничная подпрограмма, и никуда не деться. Можно, например, тупо разобрать строки такой проги в подпрограммы по 10-20 строк, и делать
DO метод1
DO метод2
...
Фокс это позволяет (PRIVATE переменные видны, подпрограммы правда не имеют смысла без контекста, и без внешних переменных, которых может быть много). Еще есть #INCLUDE файл, тоже можно "упростить" чтение кода. Но "пользы" в таком разбиении не будет.

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

of63
"красота" изложения (удобство восприятия дилетантами) - дело 10-е

Мда, и это говорит человек, которй кодит не один десяток лет.

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

Видимо, Офа не утруждает себя сопровождением своих поделок, либо постоянно варится в одном соку

Я так же сопровождаю (разбираю) свои коды (нет других!), читаю свои же комменты, матерюсь на:
"а на..зачем я так написал!" и на
"а вот это зачем?" и на
"ну чтобы не накоментить было"
"комент не соответствует коду... или я не понял коммент, или код... угадай! Сегодня вечером - крайний срок"

Доб.
> Мда, и это говорит человек, которй кодит не один десяток лет.
А я повторю, красота кода касается только разраба, или конторы, в которой он разрабит. Нефик лазить по чужим кодам, если боишься видеть неприглядную сущность разработки "на время", "за деньги", или просто код, отличный от своего.



Исправлено 1 раз(а). Последнее : of63, 03.02.18 15:42

И ты, тем не менее, считаешь, что "удобство восприятия" - дело 10?

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

Именно так. Вот Набибулина издает закон "отчитаться вот по такой форме", на след месяц (за год обычно, но бывает и за месяц-другой). Понятия в законе непонятные, аналитиги начинаю интерпретировать, ты набрасываешь код, комментиш идею, идея меняется ежедневно. Потом последние дни сдачи, ты меняешь, перегоняешь, забываешь пере/комментить, не понимаешь что написал, но аналитега устраивает. Сдаешь, напиваешься... Думаешь "щас все пойму, оформлю, закоменчу, оформлю в бронзе"... ФИК, законы и понятия сменят на следующий же год. И так последние пару-тройку лет, после того как Пу перед НГ каким-то сказал "Хватит кошмарить бизнес", вот тогда и началось

фу таким быть

Каким? Удовлетворяющим Набибулину? или Пу? или контору?

подстилкой под хотелки

Никуя себе. А ты кого удовлетворяешь? Себя? Сам собой?

исключительно так

Вот именно! А я пользу приношу, удовлетворяю чужие хотелки, за счет собственной психики, но за ЗП. Продаюсь то есть. Тебе повезло, раз на самообеспечении...

не всегда так было - и сильно жалею, что не всегда

...не понял, что было (самообеспечение, или пользоприношение), и че об этом жалеть. Все жалеют. Я жалею, что в электронщиках не получилось поучаствовать в разных "Куськиных матерях", и что в фокс попал, и что ... сложилось так, как сложилось. Шевелиться надо немного, делать над собой усилие, или кого-нибудь, кто сядет на шею и поедет попросит/заставит, и к тебе потянутся люди )

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

Саша, конечно! Как и нормальный писатель, делая абзацы, делая "эпиграфы" к абзацу, чтобы понял посторонний человек

of63
А я повторю, красота кода касается только разраба, или конторы, в которой он разрабит.

Если весь твой код пишется для того чтобы через 2-3 года быть выкинутым, ну что ж, можно немного посочувствовать, и признать - да, нет смысла утруждать себя. Только чего ж тогда обижаться, если кто то увидев сие, назовёт "нехорошими словами" Просто честно признай - да, я намеренно пишу так - мне не платят "за красоту", мне не дают времени писать хорошо, мне наплевать на того, кому придётся потом это сопровождать, т.к. я уверен что никому и не придётся, да и вообще это "одноразовый" и по определению "несопровождаемый" код.

Реалии сейчас таковы, что большинство создаваемого в мире кода НЕ ПОДХОДИТ под такой шаблон - и "живёт" код дольше чем его автор работает на данную контору/на данный проект, и коллективная разработка доминирует над "героями-одиночками"... И нормальному работодателю нужен не просто код который "работает СЕЙЧАС", а код который он сможет долго и успешно использовать (как минимум чтобы отбить средства затраченные на его создание) - в т.ч. и изменять, и исправлять (абсолютно безошибочного кода не бывает - это аксиома) не будучи в заложниках у автора "нетленки".