Метрики кода

Question

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

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

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

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

Answer 1

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

Мой предыдущий работодатель сохранил показатели сложности кода и строки кода. У них также были ограничения на длину файлов классов. Классы, которые стали слишком большими, должны были пройти проверку кода, чтобы их можно было разбить на более мелкие классы. Время от времени это была боль в прикладе, но она сохраняла то, что было чрезвычайно большой исходной базой (100 - 200 разработчиков были на проекте) довольно легко ремонтировались.

Answer 2

• Lint
• цикломатическая сложность
• К сожалению, мало еще

Answer 3

В настоящее время мы делаем тестовое покрытие с EMMA как Maven плагин. Это довольно пятно. Он точно скажет вам, сколько вашего кода выполняется вашими тестами. Мы используем JUnit для тестирования.

Answer 4

Я регулярно использую sloccount Дейва Уилера, который дает LoC, а также пробовал CCCC, хотя он немного устарел.

Answer 5

В Bell мы вычисляли Функциональные пункты по каждому проекту (см. IFPUG).

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

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

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

Sylvain.

Answer 6

Я экспериментировал с Metrics plugin for Eclipse from StateOfFlow, и мне нравится идея анализа моего кода.Конечно, не все показатели слишком ясны для меня или полезны, но из широкого спектра различных показателей, которые предоставляет плагин (в настоящее время 14, по моему подсчету), я склонен относиться к этому серьезно:

Метрики метода: Цикломатическая сложность | Количество заявлений | Количество местных жителей в области | Количество уровней

Показатели качества: Кол-во полей | Весовые методы в класс

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

Из остальных показателей, предоставляемых плагином, я нахожу их от Отсутствие сцепления в методах группы довольно трудно понять. Сегодня я начал с небольшого эксперимента, и после нескольких часов кодирования я включил поддержку Metrics для проекта. Найденные проблемы 6/7 связаны с единством, особенно неожиданным: Отсутствие сцепления в методах (общая корреляция) составляет 209%.

Мне сложно сделать что-нибудь об этом: Chidamber и Kemerer | Хендерсон-Продавцы | Общая корреляция | Pairwise Field Irrelation. Я очень склонен поднять допустимые максимумы для этих показателей, поэтому они перестанут появляться в качестве предупреждений.

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

Кстати, я бы приветствовал любые рекомендации других плагинов (Eclipse), с которыми вы могли бы столкнуться. Один из StateOfFlow обеспечивает хороший способ экспорта информации метрик в виде HTML-страниц с графиками и таблицами, а также может экспортировать метрики в файлы CSV, которые затем можно использовать в любых других утилит, которые вы можете использовать. До сих пор я наслаждаюсь плагином :)

Answer 7

Вы получаете то, что измеряете.

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

---

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

частота отказов
• Ежедневно сборки (с анализа коренных причин для неудачи), целевой < 20%
• Тестирование бега/пасс ставки (как автоматизированные и ручные тесты), целевые переменные для каждой фазы проекта; при скорости конечного запуска 100%, скорости передачи 95%
• Функция тестирования и охват принятия решения для нового кода (не являющегося пользовательским интерфейсом, без устаревших, не портированных), целевых 100% для функций API, 80% для других функций, 50 % для принятия решений
• Открытый счетчик ошибок по приоритету, цель, чтобы увидеть плоскую или уменьшающуюся кривую (достаточная емкость для исправления ошибок в команде), отсутствие открытых высокоприоритетных ошибок
• Осмотр: размер компонента, контроль, обнаруженные по степени серьезности ; чтобы получить какой-то дефект/усилие/loc эвристический показатель, чтобы убедиться, что компоненты проверены достаточно тщательно
• Статические инструменты анализа, такие как lint и некоторые инструменты для работы с конкретными доменами, проблемы с высоким приоритетом исправлены или поняты
• Оценка скорости команды против фактического спринта, цель уменьшения ошибки оценки до менее 20%

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

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

Answer 8

Essential Cyclometric Complexity является интересным, а также дает представление о том, как «неструктурирован» код.

Неструктурированный код - это использование разрывов и переходов, например, для выхода из структур управления, например, для циклов.

Однако единственный продукт, который я знаю, что дает этот показатель является McCabe IQ

Answer 9

Скотт Hanselman недавно сделал очень хороший подкаст на именно это. Попробуйте здесь: http://www.hanselminutes.com/default.aspx?showID=181

Answer 10

Я считаю, что Type Rank и метрики кода Ранга метода чрезвычайно полезны, когда вам нужно получить краткий обзор типов/методов ключей в вашем коде. Тип и метод Ранг вдохновлен знаменитым Google Page rank algorithm.

Если вы находитесь в среде .NET, NDepend вычислит тип Ранг и метода ранговой для вас (а также 80 других метрик кода)

Answer 11

Там есть довольно много научной литературы по этому вопросу. Обследование можно найти в Nachiappan Naggapan's thesis (Извините, я не смог найти лучший доступ к тезису). Другая презентация по показателям программного обеспечения - here.

Я узнал о некоторых показателях, таких как метрика потока информации Генри и Кафуры, после того, как я недавно запустил CCCC на базе кода на C++. CCCC является открытым исходным кодом и выводит исчерпывающий результат (sample), состоящий из 2-3 различных показателей.