Оценка качества кода

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

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

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

должны быть примеры. от «начал работать с Х» до «кончел работать с Х». т.е. мы хотим добиться А, делаем так. хотим Б - делаем так.

вообще, к чему я это написал.

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

Valgrid

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

сегодня он работает, завтра что-то дописали и он упал, потому что вася думал так, а на петя иначе.

Тесты? Нет, не слышал.

должны быть примеры

Это тоже часть документации.

что тесты.

вон V8 имеет тесты, а в итоге имеем доступ вне массива, причем какой-то совсем печальный.

Есть SourceMonitor, но он под офтопик.

Ещё есть SonarQube, но он с web-интерфейсом (может есть и нормальный тоже, но я не видел).

что тесты.

Тесты помогают обнаруживать ошибки. // К.О.

И совершенно не мешают иметь описание программы «с птичьего полета».

Таки позвольте не согласиться. Вот, к примеру, получил я код, в котором одна только функция на 1200 строк кода, и цикломатическая сложность этой функции 425 (!!!). Открываю, к примеру, http://gmetrics.sourceforge.net/gmetrics-CyclomaticComplexityMetric.html а там чёрным по белому «>50 = Most complex and highly unstable method». Я иду к этому Васе-Пете и говорю: Товарисч, ваш код нихрена не годится, надо эту супер-пупер-мегафункцию переписывать, а то твой код не протестируешь на все случаи, он отвалится, когда внесут какую-то маленькую строчку где-то посреди этой функции

Вот такой пример )))

Тесты тестами. Но тесты - не имеют ничего общего с темой топика.

должны быть примеры. от «начал работать с Х» до «кончел работать с Х». т.е. мы хотим добиться А, делаем так. хотим Б - делаем так.

Да ты офигел

на практике я офигевал от кода без описания. потому что есть описание метода foobar() например, а на практике надо перед ней сделать kokoko() и blablabla(). и это узнаешь только после адовых мучений, потому что это СЕКРЕТ.

ну это какие-то крайние случаи явного рукожопия.

а бывает гадость которая написано очень «правильно». вот у нас на работе прямо сейчас встал вопрос переписывания с около-нуля проекта на 50к строк. но уже всё, уперлись в кучу проблем заложеных изначально. большую часть кода кстати можно даже выкинуть, например отрисовка карт на 5к строк заменима на ~1500 строк со значительными улучшениями.

почему так произошло? потому что не думали, когда всю эту херню городили.

качество кода

Обратно пропорционально квалификации программиста, способного его поддерживать.

Наличие тестов резко повышает качество кода (ну или как минимум надёжность).

Почему перед ней? На функциональном языке пишешь? В нормальных это либо в конструктор кладут, либо проектируют нормально, чтобы такой необходимости не было.

ну просто так надо. разрабы решили что надо так но никому не сказали.

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

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

Наличие тестов резко повышает качество кода (ну или как минимум надёжность).

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

Я иду к этому Васе-Пете и говорю: Товарисч, ваш код нихрена не годится, надо эту супер-пупер-мегафункцию переписывать

Если ты не начальник Васи-Пети, то идешь дальше.

То есть вы тесты не пишете в принципе?

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

То есть вы тесты не пишете в принципе?

Вы всегда необоснованные предположения высказываете, или это перформанс?

Если бы вы использовали менее изысканный способы излагать свои мысли - я бы не задавал глупых вопросов.

ну это был интерфейс аппаратного енкодера h264/avc для fglrx в первом случае, а во втором это Qt. 5.4.1 и 5.7 пробовал, везде одна проблема, надо QStyleProxy тащить. QPalette не работает как обещано и нигде про это не сказано. что ж мне теперь, Qt не пользоваться?

что касается fglrx, то в моем случае это было как раз «торчать наружу» т.к. мы сами сидели внутре.

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

Ок, Вы сказали:

Наличие тестов резко повышает качество кода

Это императив, безусловный, и, очевидно, в общем случае неверный. На что я и обратил Ваше внимание. Как это связано с тем пишу я тесты или нет - загадка.

Вы считаете (если я вас правильно понимаю), что тесты не улучшают качество кода. Раз так - значит они не нужны.

Или вы считаете тесты бесполезными, но всё равно их пишите?

QPalette не работает как обещано и нигде про это не сказано.

Шта?

Императив на императиве императивом погоняет.

Оценка качества кода

Нет тестов - на помоечку.

Но это, конечно, далеко не достаточное условие хорошего качества кода. А необходимое

Вы считаете (если я вас правильно понимаю), что тесты не улучшают качество кода.

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

Или вы считаете тесты бесполезными, но всё равно их пишите?

считаю, что написание тестов требует определенной квалификации

Написание качественного кода вообще требует квалификации.

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

Если ты не начальник Васи-Пети, то идешь дальше.

Серьёзно??? Я не начальник Васи-Пети, но завтра Вася-Петя и ещё один третий работают в конторе последний день. Не шутка. Просто недели три назад начались проблемы в одном проекте в соседнем отделе. Меня «попросили» найти ошибку (ну, типа, авторитет). Я посмотрел, сказал, что надо всё выбрасывать и переписывать. У начальства истерика, но согласились. Вася-Петя-ХЗ_как_зовут ищут с начала месяца новую работу. Кстати, один из моих аргументов, был как раз: цикломатическая сложность и как следствие непредсказуемость и т.д.

Ну вот как-то так )))

Я посмотрел, сказал, что надо всё выбрасывать и переписывать.

Мой опыт говорит, что такого ответа стоит ожидать в 99.[9]% случаях, в независимости от любых качеств эксперта.

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

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

Каждая первая контора. Сначала тебе нужно «ПРЯМ ВОТ СЕЙЧАС ДЕЛАЙ, ОНО ЕЩЕ НА ВЧЕРА НАДО БЫЛО», затем вот так, а потом это говно приходится кому-то выгребать. Когда выгребать становится невыносимо сложно, происходит то, что описал оратор выше.

Таки да. Когда начинаются косяки в проекте и разработчики неделями не могут их пофиксить (фиксят одно - выскакивает другое, потом третье и т.д.), то начальство задалбывает платить за неизвестно «заработает или нет». Начальство берёт проверенного людишку из другого отдела на заценить. А дальше как получится. Я уже не раз вытаскивал у них просроченные проекты. В этот раз там не вытащить. Надо переделывать. Много переделывать. Проект завалили, виновных разогнали. Д'Артаньяна из себя не строю. Проза жизни.

Мой опыт говорит, что такого ответа стоит ожидать в 99.[9]% случаях, в независимости от любых качеств эксперта.

Маленький у вас опыт. В 80% случаях можно пофиксить

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

качество кода - это как какашки. каждому нравятся свои и не нравятся чужие.

Нет

мне, любителю минимализма, количество и содержание холиваров с любителями flexibility и модных смузи-технологий, говорит обратное. и согласен с оратором выше что в 99% случаев первое желание - переписать всё нахрен. После детального анализа требований и кода в 80% случаев убирается очевидная чушь вида подавления ошибок и неправильная работа с контейнерами, а остальное часто остаётся, если там нет багов. Но дали бы волю - конечно переписать так, как нравится. Только нравится каждому своё.

хотя есть ещё одно хорошее правило. если автор кода только несвязно мычит на вопрос «что делает этот код?», то код в любом случае переписывается, пока автор не начинает связно рассказывать что в коде происходит или это не становится очевидно после первого прочтения кода.

И в большом количестве случаев комментарии автора становятся комментариями в коде. В «самодокументированный» код не верю и не видел такого, кроме тривиального.

если при чтении кода не возникает желания заглянуть в документацию или сверится со стандартами, значит код - Ok.

Вообще чтение и понимание кода человеком, должно быть главным критерием, со всем прочим должны справляться компиляторы.

К сожалению автоматизировать сии проверки невозможно :-( Только ревью

Написание качественного кода вообще требует квалификации.

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

так что я из таких контор обычно просто сваливаю, разгребать авгиевы конюшни при тотальном непонимании руководства (а обычно рыба портится с головы) - это работа для настоящих Гераклов и МакЛаудов, к которым я себя не отношу

Для чего кужны тесты и их виды - сто раз расписано в литературе. И чем они не являются, так же описано.

именно

WTF/min весьтимо.

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

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

Кстати, поддерживаю

если автор кода только несвязно мычит на вопрос «что делает этот код?»

Это уровень лаб в МГТУ какой-то Ж)

Единственная надёжная оценка кода, которую я знаю, это «чё за нах в минуту»: http://www.osnews.com/story/19266/WTFs_m

У каждого модуля должно быть:

• Явно быть описаны зависимости (причем если он использует сторонние библиотеки, то не подключать общий заголовочный файл библиотеки, а цеплять только тот функционал, который ему нужен), эти зависимости должны быть описаны для чего и как используются.
• Внутренний и внешний API должны быть разделены
• Авто тесты для программистов, которые будут дальше разрабатывать/поддерживать твой модуль; тесты для отдела тестировщиков с четкими и ясными сценариями использования.
• Внутренняя документация (можно через doxygen) для разрабов модуля; внешняя документация для тех кто хочет использовать твой модуль извне(естественно надо через вики, или каким нибудь другим прямым текстом описать как и для чего использовать твой внешний api), желательно еще прикрепить UML модели модуля (это уже по вкусу, можно и без них обойтись)
• Протокол взаимодействия должен быть унифицирован для всех модулей(или по крайне мере для группы модулей) и явно описан в корпоративной спецификации

Вроде все, если я что-то упустил то поправьте.

Теперь по самому коду: Тут тоже можно написать простынь из текста для структуры качественного кода, особенно если в бой идет многопоточность и мета-программирование, но я лишь оставлю ссылку к чему лучше всего придерживаться http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines Причем я даже не говорю, что это для всех должна быть АБСОЛЮТНАЯ правда(её нет), просто авторитетность авторов статьи >> авторитетности мнения большинства обитателей лора(включая меня)

Перечитай свой комментарий после полугода работы программистом.

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

адово плюсую.

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