LINUX.ORG.RU

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

 ,


3

6

Всем привет!

Интересно, чем вы пользуетесь для сабжа? Интересно оценить сложность среднего размера проекта (где-то 1,2Мб С++ кода). Первое, что в голову пришло: cppcheck просто как анализатор того, сколько накосячено; pmccabe для заценить сколько ветвлений в функциях. А чем посоветуете оценить взаимосвязи модулей? Ну и вообще subj )))

Всем заранее спасибо,
velik


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

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

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

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

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

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

ckotinko ☆☆☆ ()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от erfea

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от ckotinko

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

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

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

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

что тесты.

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

ckotinko ☆☆☆ ()

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

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

xaizek ★★★★★ ()
Ответ на: комментарий от ckotinko

что тесты.

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от ckotinko

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

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

velikS ()
Ответ на: комментарий от RazrFalcon

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

velikS ()
Ответ на: комментарий от ckotinko

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

Да ты офигел

panzerito ()
Ответ на: комментарий от panzerito

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от velikS

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

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

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

ckotinko ☆☆☆ ()

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

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

panzerito ()
Ответ на: комментарий от velikS

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от ckotinko

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

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

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

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

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от RazrFalcon

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

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

shty ★★★★★ ()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от velikS

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

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

panzerito ()
Ответ на: комментарий от ckotinko

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

peregrine ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

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

shty ★★★★★ ()
Ответ на: комментарий от shty

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от peregrine

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

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

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от RazrFalcon

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

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

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

shty ★★★★★ ()
Ответ на: комментарий от shty

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

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от ckotinko

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

Шта?

RazrFalcon ★★★★★ ()

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

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

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

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

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

shty ★★★★★ ()
Ответ на: комментарий от shty

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от panzerito

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

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

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

velikS ()
Ответ на: комментарий от velikS

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

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

panzerito ()
Последнее исправление: panzerito (всего исправлений: 1)
Ответ на: комментарий от velikS

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

panzerito ()
Последнее исправление: panzerito (всего исправлений: 1)
Ответ на: комментарий от panzerito

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

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

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

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

velikS ()
Ответ на: комментарий от panzerito

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

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

velikS ()

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

dzidzitop ★★ ()
Ответ на: комментарий от dzidzitop

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

Нет

velikS ()
Ответ на: комментарий от velikS

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

dzidzitop ★★ ()
Ответ на: комментарий от velikS

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

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

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 2)

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

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

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

MKuznetsov ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

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

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

именно

shty ★★★★★ ()
Ответ на: комментарий от shty

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

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

Deleted ()
Ответ на: комментарий от dzidzitop

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

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

Deleted ()

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

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

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

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

maxis11 ()
Ответ на: комментарий от maxis11

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

panzerito ()
Ответ на: комментарий от dzidzitop

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

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

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

vtVitus ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.