Какие метрики кода убеждают вас в том, что предоставленный код является & ldquo; crappy & rdquo ;? [закрыто]

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

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

Выше = лучше кодируют.

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

value > 1 -> bad (too many comments)

value < 0.1 -> bad (not enough comments)

Корректируют числовые значения согласно Вашему собственному опыту;-)

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

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

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

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

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

Количество бесполезных комментариев к значимым комментариям:

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

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

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

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

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

   long myLong = (long)(int)num;

Не автоматическое решение, но я нахожу WTF's в минуту полезным.

_{(источник: osnews.com )}

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

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

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

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

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

Нижняя строка, человек превосходит машину.

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

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

• Профанация в комментариях.

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

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

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

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

Моя ставка: комбинация цикломатической сложности (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#: (

Одни только метрики не определяют дрянной код. Однако они могут определить подозрительный код.

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

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

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

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

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

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

This hilarious blog post on The Code C.R.A.P Metric could be useful.

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

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