Какие метрики кода убеждают вас, что предоставленный код "дрянной"?
Строки кода на файл, методы на класс, цикломатическая сложность и так далее. Разработчики сопротивляются и обходят большинство, если не все из них! Об этом есть хорошая статья о Джоэле (сейчас нет времени ее найти).
Какие метрики кода вы рекомендуете использовать для автоматической идентификации "дерьмового кода"?
Что может убедить большинство (вы не можете убедить всех нас в какой-то дурацкой метрике!:O)) разработчиков в том, что этот код "дерьмо".
Только метрики, которые могут быть автоматически измерены, учитываются!
27 ответов
Никакие показатели, касающиеся стиля кодирования, не являются частью такого предупреждения.
Для меня это статический анализ кода, который всегда может быть включен:
- цикломатическая сложность (обнаруживается с помощью checkstyle)
- обнаружение цикла зависимости (например, с помощью findbugs)
- критические ошибки, обнаруженные, например, findbugs.
Я бы поставил тест покрытия на втором этапе, так как такие тесты могут занять время.
Не забывайте, что "дерьмовый" код обнаруживается не метриками, а комбинацией и развитием (как в " тренде") метрик: см. Вопрос " Чем увлекаются метрики кода?".
Это означает, что вам не нужно просто рекомендовать метрики кода, чтобы "автоматически идентифицировать" дрянной код "", но вы также должны порекомендовать правильную комбинацию и анализ тенденций для соответствия этим метрикам.
Что касается кого-то, я разделяю ваше разочарование;), и я не разделяю точку зрения tloach (в комментариях к другим ответам): "Задайте неопределенный вопрос, получите неопределенный ответ", - говорит он, - ваш вопрос заслуживает конкретный ответ.
Не автоматизированное решение, но я считаю WTF за минуту полезным.
(источник: osnews.com)
Количество закомментированных строк на строку производственного кода. Обычно это указывает на неаккуратного программиста, который не понимает контроль версий.
Количество предупреждений, которые выдает компилятор, когда я делаю сборку.
Разработчики всегда заботятся о том, чтобы показатели использовались против них, и называть "дрянным" кодом не очень хорошее начало. Это важно, потому что, если вы беспокоитесь о том, что ваши разработчики играют вокруг них, не используйте метрики для чего-либо, что им выгодно / не выгодно.
Это работает лучше всего, не позволяя метрике сообщать вам, где код дрянной, но используйте метрику, чтобы определить, где вам нужно искать. Вы просматриваете обзор кода, и решение о том, как решить проблему, принимается разработчиком и рецензентом. Я бы тоже ошибался на стороне разработчика против метрики. Если код все еще отображается в метрике, но рецензенты считают его хорошим, оставьте его в покое.
Но важно помнить об этом игровом эффекте, когда ваши показатели начинают улучшаться. Отлично, теперь у меня 100% охват, но хороши ли юнит-тесты? Метрика говорит мне, что я в порядке, но мне все еще нужно проверить это и посмотреть, что привело нас туда.
Итог, человек превосходит машину.
Несуществующие тесты (выявлено по покрытию кода). Это не обязательно показатель того, что код плохой, но это большой предупреждающий знак.
Ненормативная лексика в комментариях.
Только метрики не идентифицируют дрянной код. Однако они могут идентифицировать подозрительный код.
Есть много метрик для ОО программного обеспечения. Некоторые из них могут быть очень полезны:
- Средний размер метода (как в LOC/Statements, так и в сложности). Большие методы могут быть признаком плохого дизайна.
- Количество методов, переопределенных подклассом. Большое число указывает на плохой дизайн класса.
- Индекс специализации (количество переопределенных методов * уровень вложенности / общее количество методов). Большие числа указывают на возможные проблемы в диаграмме классов.
Существует гораздо больше жизнеспособных показателей, и их можно рассчитать с помощью инструментов. Это может быть хорошим подспорьем в определении дерьмового кода.
- глобальные переменные
- магические числа
- соотношение код / комментарий
- сильная связь (например, в C++ вы можете измерить это, посмотрев на отношения классов или количество файлов cpp/header, которые взаимно включают друг друга
- const_cast или другие типы приведения в пределах одной и той же кодовой базы (не с внешними библиотеками)
- большие части кода закомментированы и оставлены там
Мой личный любимый флажок предупреждения: комментируйте свободный код. Обычно означает, что кодер не переставал думать об этом; Кроме того, это автоматически усложняет понимание, что увеличивает соотношение дерьма.
Моя ставка: сочетание цикломатической сложности (CC) и покрытия кода из автоматических тестов (TC).
CC | TC
2 | 0% - good anyway, cyclomatic complexity too small
10 | 70% - good
10 | 50% - could be better
10 | 20% - bad
20 | 85% - good
20 | 70% - could be better
20 | 50% - bad
...
crap4j - возможный инструмент (для Java) и объяснение концепции... в поисках C# дружественного инструмента:(
На первый взгляд: грузовое культовое применение кодовых идиом.
Как только я посмотрю поближе: явные ошибки и неправильные представления программиста.
Много преобразований в и из строк. Как правило, это признак того, что разработчик не понимает, что происходит, и просто пробует случайные вещи, пока что-то не работает. Например, я часто видел такой код:
object num = GetABoxedInt();
// long myLong = (long) num; // throws exception
long myLong = Int64.Parse(num.ToString());
когда они действительно хотели:
long myLong = (long)(int)num;
Количество бесполезных комментариев к значимым комментариям:
'Set i to 1'
Dim i as Integer = 1
Я не верю, что есть такая метрика. За исключением кода, который на самом деле не выполняет то, что должен (а это еще один дополнительный уровень глупости), "дрянной" код означает код, который трудно поддерживать. Обычно это означает, что сопровождающему трудно понять, что всегда в некоторой степени субъективно, как плохое письмо. Конечно, есть случаи, когда все соглашаются с тем, что написание (или код) является дерьмовым, но очень сложно написать для него метрику.
Плюс все относительно. Код, выполняющий очень сложную функцию в минимальной памяти, оптимизированной для каждого последнего цикла скорости, будет выглядеть очень плохо по сравнению с простой функцией без ограничений. Но это не дерьмо - просто делать то, что нужно.
- Следите за соотношением классов Pattern и стандартных классов. Высокое соотношение будет указывать на патетит
- Проверьте магические числа, не определенные как константы
- Используйте утилиту сопоставления с образцом для обнаружения потенциально дублированного кода
К сожалению, я не знаю метрики. Имейте в виду, что независимо от того, что вы выберете, программисты будут играть в систему, чтобы их код выглядел хорошо. Я видел, что повсеместно вводится любая "автоматическая" метрика.
Иногда вы просто знаете это, когда видите это. Например, сегодня утром я увидел:
void mdLicense::SetWindows(bool Option) {
_windows = (Option ? true: false);
}
Я просто должен был спросить себя: "Зачем кому-то это делать?".
Я использую многоуровневый подход, при этом первый уровень - это разумная читаемость, компенсируемая только сложностью решаемой проблемы. Если он не может пройти тест на читабельность, я обычно считаю код менее чем хорошим.
Покрытие кода имеет определенную ценность, но в остальном я склонен больше полагаться на профилирование кода, чтобы определить, является ли код дрянным.
Соотношение комментариев, которые включают ненормативную лексику к комментариям, которые этого не делают.
Выше = лучший код.
Строки комментариев / Строки кода
value > 1 -> bad (too many comments)
value < 0.1 -> bad (not enough comments)
Отрегулируйте числовые значения в соответствии с вашим собственным опытом;-)
Ну, есть несколько разных способов, которые вы могли бы использовать, чтобы указать, является ли код хорошим кодом. Ниже приведены некоторые из них:
Связность. Что ж, блок кода, будь то класс или метод, если обнаруживается, что он обслуживает несколько функций, может оказаться, что код имеет меньшую согласованность. Код с меньшей связностью может быть назван как низкий для повторного использования. Это также может быть названо как код ниже в удобстве обслуживания.
Сложность кода. Для определения сложности кода можно использовать цикломатическую сложность МакКейба (количество точек принятия решения). Высокая сложность кода может использоваться для представления кода с меньшим удобством использования (трудно читать и понимать).
Документация: Код с недостаточным количеством документов также может свидетельствовать о низком качестве программного обеспечения с точки зрения удобства использования кода.
Проверьте следующую страницу, чтобы прочитать о контрольном списке для проверки кода.
TODO: комментарии в производственном коде. Просто показывает, что разработчик не выполняет задачи до завершения.
Это веселое сообщение в блоге о метрике кода CRAP может быть полезным.