Быстрота работы программы же!

java, python, etc = говнокод
c/c++ = 50/50

Количество дефектов на N строк кода.

Я ж написал, что одинаковая плюс-минус лапоть.

Можно ловить лапшекод через цикломатическую сложность например.
Какую-то околокоммерческую оценку получить через время затраченное на написание и последующую переделку или исправление багов.

Лингвисты, в студию!

Код пишется на языках программирования. Эти математические абстракции не зря называются «языками». Предположим у вас есть две театральных пьесы, какие «объективные критерии качества» вы можете к ним применить?

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

Это наверное критерий, да, но он пост-критерий, хотя наверное можно количество предупреждений от анализатора кода использовать.

Но тем не менее не четкий. В принципе может быть и так, что в глючной программе все красиво вроде бы, а в корректной перлы навроде где-то реально проскочившего if (a.ToString()==«TRUE) {....} С другой стороны такой прием может зачем-то понадобиться и нормальному разработчику, например, если это автосгенерированный код или так проверяется что-то нетривиальное, что иным способом сложно узнать (например, если где-то используется вместо true другое слово, не знаю бывает ли).

Во, хорошая аналогия! Но тем не менее споры по поводы хорошая или плохая пьеса, книга, как и код редко бывают. Говнокод или что-то приличное довольно очевидно любому нормальному программисту.

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

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

Количество аргументов у функций. Нет аргументов — хорошо, один аргумент — нормально, два — сойдёт, три и более — плохо.

Старая добрая метрика: количество строк в функции. Больше двадцати — тревожный звоночек.

То же самое, но для классов. Не путать с количеством ответственностей (буква S из принципа SOLID), которое должно быть строго равно единице.

Это то, что навскидку вспоминается из хорошей книги «Чистый код» за авторством Р. Мартина.

Дарьядонцова тоже очевидна любому нормальному владельцу головного мозга.

Кроме верблюда в каментах сплошная ахинея и бредни старпёров.

Нет никаких объективных критериев, только экспертная оценка. Качество кода — трудноформализуемое понятие!

качества
объективного

Объективные критерии задаются изначально. У тебя их нет и ты их от кого-то требуешь. Давай ты сам с ними для начала определишься, а затем будешь проверять свою программу в соответствии с этими критериями. Скажем время выполнения программы. Или объем занимаемой памяти. Все остальное - наработанные практики и анализ статистических данных.

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

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

И потому просто так взять и объективно оценить код нельзя напрямую.

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

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

нормальных программистов не существует, это миф! У каждого свои тараканы в голове, и код оценивается исходя из просуммированных предпочтений всех тараканов

А вообще, вот это если в програме количество операторов «if» такое, что остаток от деления этого числа на 7 равен 5 или 3, то говнокод, если 0 - рулез надо будет оформить в виде «критерия praseodim» и гонять с остальными тестами при сборке.

Объективные критерии задаются изначально. У тебя их нет и ты их от кого-то требуешь. Давай ты сам с ними для начала определишься, а затем будешь проверять свою программу в соответствии с этими критериями.

Говорят же «это говнокод» и примеры даже есть над которыми смеются. А мне интересно стало, есть ли что-то объективное в такой оценке или она всегда субъективна?

Попытался что-то придумать. Например, если в программе много goto без нормального повода, то есть выхода из вложенного цикла или обработки исключений в языке, где они явно не поддерживаются. - это скажем балл говнокодости за каждый такой оператор. Но опять-таки, может быть какой-то редкий случай, когда это оправдано. Или в программе функции длиной больше 100 строчек - +1 балл за каждые 100 лишних строк.

Критерий только один.

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

Выполнение задачи

Наличие сбоев

Скорость выполнения

Сопровождаемость

Если да, то по ним и мерить.

объективные критерии качества программного кода

Но зачем, чтобы дрочить на него? Если программа отвечает требованиям пользователя и принятым в её области стандартам - это хорошая программа.

Первые три пункта объективные и теоретически можно представить, что разные программы будут одинаковы по ним, а вот сопровождаемость уже субъективна. Статистически, наверное можн о сказать, что если из 10 программистов решили, что программа «А» лучше сопровождается, чем «Б» восемь программистов, а 2, что «Б» , то «А» лучше. Но вот объективно трудно сравнить.

Тут предыдущий пост был про сопровождаемость. Это близко к понятию качества кода и имеет значение.

Говорят же «это говнокод»
наработанные практики

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

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

Disclaimer: несогласные с этим утверждением могут дальше не читать, хипстерам дальше не читать.

A = mtbf / (mtbf+mttr)

A - availability mtbf - mean time before failure mttr - mean time to repair

Вот все перечисленные выше параметры так или иначе входят либо в mtbf (архитектура, технологии, число багов на строку) либо в mttr («сопровождаемость», легкость исправления, качество документации, используемое окружение и т.п.).

Есть методологии для расчетов (теоритических и практических), но это уже частности.

Это такой вброс?

Допустим, % покрытия тестами.

https://ru.wikipedia.org/wiki/Цикломатическая_сложность например

Можно тут глянуть http://docs.sonarqube.org/display/SONAR/Metric Definitions

Твой код лучший, не твой - говнокод. Не фиг тут философские сопли разводить.

задокументированные
трассировку этих требований на участки кода

Это обратная документация и это ужас. Код сам по себе должен быть самодокументируемый.

Иначе мы получаем функции, которые не пойми как работают, но работают. Поддерживать их невозможно.

Та, которая прошла формальную верификацию.

Говнокод:

str = str.modify
somefunc str

somefunc str.modify

есть ли что-то объективное в такой оценке или она всегда субъективна?

Есть.

1. Соответствие правилам оформления кода в компании. Они вполне конкретны и часто в компании есть анализаторы, которые будут выдавать что где и почему в твоей программе не соотв. правилам.

2. Разумные примеры:

а) если в коде присутствуют однобуквенные переменные введенные программистом k, n и пр. — это жирный минус к коду, если есть однобуквенная переменная l — это просто говнище, а не код. Вполне конкретный критерий...

б) Количество команд в одной строчке > 2 — минус к коду...

в) Отсутствие комментариев перед определением функции — минус к коду...

и пр.

В целом же, конечно, это все критерии для субъективных показателей:

1. как быстро другой программист поймет твой код

2. насколько удобно код модифицировать

3. насколько он удобен для повторного использования

4. насколько он защищен

5. насколько он быстр (только в задачах где это нужно, в остальных же ПОНЯТНОСТЬ кода важнее скорости, т.е. можно пожертвовать скоростью, напр. внести что-то доп. в цикл, чтобы код был понятней)

Где плюют на DRY, на выходе получают говнокод

после первой же правки код обрастает костылями, часто еще в процессе написания :)

если в коде присутствуют однобуквенные переменные введенные программистом k, n и пр. — это жирный минус к коду, если есть однобуквенная переменная l — это просто говнище, а не код. Вполне конкретный критерий...

переменные-счётчики внутри циклов принято делать однобуквенными, в математических функциях вида tang(double x) или pow(double a, double b) не вижу смыла отводить на переменную более чем одной буквы, в физических функциях вида force(double a, double m), а кроме этого, во всех ф-циях, где назначение переменной самоочевидно string copy(string a, string b)

нет

если в коде присутствуют однобуквенные переменные введенные программистом k, n и пр. — это жирный минус к коду, если есть однобуквенная переменная l — это просто говнище, а не код. Вполне конкретный критерий...

доо, loopCounter, arrayIndexI и прочее конечно читабельнее, доо...

да

Где плюют на DRY, на выходе получают говнокод

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

В треде нет целевой функции. Что требуется? Легкая расширяемость/допиливаемость? Скорость реализации? Найм дешевых макак? Работоспособность везде или наоборот близкая заточка под парадигмы и вектор текущей платформы? Как только появится список приоритетов, сразу можно накидать и набор показателей.

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

loopCounter

anotherLoopCounterWhichWasIntroducedBecauseOfABugInVisualCPlusPlusWhichCausesVariablesDeclaredInsideForAsALoopVaribleToLeakThroughForBlockBoundariesOhMyGoshMyManagerForcesMeToNameVariablesAtLeastSixCharactersLong

выбрать произвольный критерий «лучше относительно чего» и сравнить :) Если оптимизируем скорость — херим проверки ошибок «которые никогда не произойдут» и зажор памяти, если память — кладем на скорость. Если надежность — тут спектор вариантов от «плазма не падает», до драконовских гайдлайнов, требований к покрытию тестами, соответствию стандартам де-факто и де-юре и формальной верификации. Если сопровождаемость/масштабируемость/понимабельность кодирующими за еду бибизянами — добро пожаловать в соотвествующие секты «обезьян дрочащих на недостаточно интенсивно» :) Если оптимизируется набор критериев — рисуешь такой магический квадрат с квадрантами «скорость-память-сопровождабельность-масштабируемость-надежность» выбрать любые (не все — потому что крякнеш от статистического матана и количества коэффициентов), меряешь профайлерами и смотришь, куда график выруливает от подхлестывания нанятых по объявлению лебедя-рака-щуков

Где fine-grained и DRY понимают буквально получают нечитабельную кашу редиректов, слоев абстракций и «паттернов погромирования», невместную в отдельный офисный моск вложенность и фактическую несопровождабельность (как раз то, от чего стремились уйти внедряя DRY :)) Особенно DRY противопоказан пионерам, которых попросили написать набор «ну очень простых программок» для примеров использования $Frameworkname, в которые они пихают все композиционные фишки, про которые успели узнать: ехал MVC через MVC... В helloworld, который в итоге с трудом понимает сам пионер через месяц, когда надо проапдейтить «примеры для быстрого старта» на новую версию $Frameworkname :)

Известно же давно, это «wtf per minute»

http://commadot.com/wtf-per-minute/

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

Если честно, не очень понял тебя
И да, MVC говно

А какую программу проще поддерживать и расширять?

чрезмерная «гибкость и настраиваемость», структурирование ради структурирования, а не в терминах задачи, и прочий карго-культизм — так же вредны, как старая добрая «лапша», копипаста и хардкод :)