Какая метрика кода убеждает вас в том, что предоставленный код "crappy"?

Ответ 1

Никакие метрики, касающиеся стиля кодирования, не являются частью такого предупреждения.

Для меня это примерно статический анализ кода, который действительно может быть 'on' все время:

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

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

Не забывайте, что "дрянные" коды не обнаруживаются метриками, а комбинацией и эволюцией (как в "тренде" ): см. Каково увлечение кодом метрики?.

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

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

Ответ 2

Не автоматизированное решение, но я нахожу WTF в минуту полезной.

WTF за минуту http://www.osnews.com/images/comics/wtfm.jpg

Ответ 3

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

Ответ 4

Число пронумерованных строк на строку производственного кода. Как правило, это указывает на неаккуратного программиста, который не понимает контроль версий.

Ответ 5

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

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

Но важно иметь в виду этот игровой эффект, когда ваши показатели начинают улучшаться. Отлично, теперь у меня 100% -ый охват, но явные тесты на тестирование? Метрика говорит мне, что я в порядке, но мне все еще нужно проверить это и посмотреть, что привело нас туда.

В нижней строке, человек ковыряет машину.

Ответ 6

число глобальных переменных.

Ответ 7

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

• Отклик в комментариях.

Ответ 8

Метрики сами по себе не идентифицируют дрянной код. Однако они могут идентифицировать подозрительный код.

Существует множество показателей для программного обеспечения OO. Некоторые из них могут быть очень полезными:

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

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

Ответ 9

• глобальные переменные
• магические числа
• код/​​комментарий
• тяжелая связь (например, на С++ вы можете измерить это, посмотрев на отношения классов или количество файлов cpp/header, которые пересекают друг друга
• const_cast или другие типы кастингов в одной и той же базе кода (а не w/external libs)
• большие фрагменты кода закомментированы и оставлены там

Ответ 10

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

Ответ 11

Моя ставка: сочетание циклической сложности (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) и объяснение концепции... в поисках дружественного инструмента С#: (

Ответ 12

На первый взгляд: грубое применение идиом кода.

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

Ответ 13

Число бесполезных комментариев к содержательным комментариям:

'Set i to 1'
Dim i as Integer = 1

Ответ 14

Я не верю, что есть такая метрика. За исключением кода, который на самом деле не делает то, что он предположил (что является целым дополнительным уровнем crappiness), 'crappy' code означает код, который трудно поддерживать. Это обычно означает, что разработчик понимает, что это всегда в какой-то мере субъективная вещь, как плохое письмо. Конечно, есть случаи, когда все согласны с тем, что письмо (или код) дрянное, но очень сложно написать для него метрику.

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

Ответ 15

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

Ответ 16

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

   object num = GetABoxedInt();
//   long myLong = (long) num;   // throws exception
   long myLong = Int64.Parse(num.ToString());

когда они действительно хотели:

   long myLong = (long)(int)num;

Ответ 17

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

Ответ 18

Я удивлен, что никто не упомянул crap4j.

Ответ 19

Иногда вы просто знаете это, когда видите это. Например, сегодня утром я увидел:

void mdLicense::SetWindows(bool Option) {
  _windows = (Option ? true: false);
}

Мне просто нужно было спросить себя: "Почему кто-нибудь когда-нибудь сделает это?".

Ответ 20

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

Ответ 21

Соотношение комментариев, которые включают профанацию к комментариям, которые этого не делают.

Более высокий = лучший код.

Ответ 22

Строки комментариев/Строки кода

value > 1 -> bad (too many comments)

value < 0.1 -> bad (not enough comments)

Отрегулируйте числовые значения в соответствии с вашим собственным опытом; -)

Ответ 23

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

Ответ 24

TODO: комментарии в производственном коде. Просто показывает, что разработчик не выполняет задачи до завершения.

Ответ 25

Методы с 30 аргументами. На веб-сервисе. Это все.

Ответ 26

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

• Согласованность: ну, блок кода, будь то класс или метод, если обнаруживается, что он обслуживает несколько функций, тогда код может быть найден ниже в связности. Кодекс ниже в связности можно назвать минимальным для повторного использования. Это также можно назвать кодом ниже в ремонтопригодности.

  • Сложность кода. Для определения сложности кода можно использовать циклическую сложность McCabe (количество точек принятия решений). Сложная сложность кода может быть использована для представления кода с меньшим удобством использования (трудно читать и понимать).

  • Документация: код с недостаточным документом также может относиться к низкому качеству программного обеспечения с точки зрения удобства использования кода.

Ознакомьтесь с следующей страницей, чтобы прочитать checklist для просмотра кода.

Ответ 27

Этот веселый пост в блоге Код C.R.A.P Metric может быть полезен.