Аналитические инструменты сложности кода вне цикломатической сложности
На основе ответа Оливье Рефало
if [ $# -eq 2 ]
then
echo "Setting tracking for branch " $1 " -> " $2
git branch --set-upstream $1 $2
else
echo "-- Local --"
git for-each-ref --shell --format="[ %(upstream:short) != '' ] && echo -e '\t%(refname:short) <--> %(upstream:short)'" refs/heads | sh
echo "-- Remote --"
REMOTES=$(git remote -v)
if [ "$REMOTES" != '' ]
then
echo $REMOTES
fi
fi
Показывает только локальный с настроенной дорожкой.
Напишите его на скрипте под названием git-track на вашем пути, и вы получите команду git track
Более подробную версию на https : //github.com/albfan/git-showupstream
6 ответов
По моему опыту, наиболее важными показателями при рассмотрении ремонтопригодности кода являются:
- Цикломатическая сложность, чтобы идентифицировать большие фрагменты кода, которые, вероятно, трудно понять / изменить.
- Вложенность глубины, чтобы найти похожие места (высокая глубина вложения автоматически означает высокий CC, но не обязательно наоборот, поэтому важно следить за обеими сторонами).
- Разверните веером, чтобы лучше видеть отношения между методами / классами и фактическая важность отдельных методов.
При изучении кода, написанного другими, часто бывает полезно включать динамические методы. Просто запустите распространенные сценарии использования с помощью профилировщика / инструмента покрытия кода, чтобы обнаружить:
- Код, который на самом деле выполняется много (профилировщик отлично подходит для этого, просто игнорируйте информацию о времени и вместо этого посмотрите на счетчик попаданий).
- Покрытие кода отлично подходит для поиска (почти) мертвого кода. Чтобы вы не тратили время на рефакторинг кода, который в любом случае выполняется редко.
Обычные подозреваемые, такие как профилировщик, инструмент покрытия кода и метрики, обычно помогут вам получить данные, необходимые для проведения этих оценок.
Обычные подозреваемые, такие как профилировщик, инструмент покрытия кода и метрик, обычно помогут вам получить данные, необходимые для проведения этих оценок.
Обычные подозреваемые, такие как профилировщик, инструмент покрытия кода и метрик, обычно помогут вам получить данные, необходимые для проведения этих оценок.
The static analysis tools you already use are pretty standard. If you're using Eclipse, try looking here for more code analysis tools.
Emma provides analysis of code coverage, though this is really for testing.
Я никогда не использовал его, но нашел это довольно интересным и многообещающим:
http://erik.doernenburg.com/2008/11/how-toxic-is-your-code /
И я использовал это и нашел его чрезвычайно полезным, потому что хорошая визуализация зависимостей
http://www.headwaysoftware.com/products/structure101/index.php
Google Testability Explorer проверяет, например, синглтоны и другие статические предметы, которые плохо пахнут в дизайне. Metrics - это плагин Eclipse, который измеряет почти все метрики кода, известные человечеству. Я использовал и могу рекомендовать оба варианта.
Sonar пытается определить "горячие точки" сложности и ремонтопригодности, комбинируя результаты различных инструментов с открытым исходным кодом (включая PMD и Findbugs). Он хорошо интегрируется с Maven и серверами CI (особенно Hudson).
РЕДАКТИРОВАТЬ от extraneon
Существует сайт Sonar , где анализируется множество проектов с открытым исходным кодом. Я думаю, это неплохо показывает, сколько правил применяется и насколько далеко заходит детализация. Вы, конечно, также можете отключить правила, которые вам не интересны.
Здесь объяснение метрик.
Инструмент NDepend для кода .NET позволит вам проанализировать многие аспекты сложности кода, включая такие показатели кода, как: Цикломатическая сложность, глубина вложенности, отсутствие согласованности методов, покрытие тестами...
... включая анализ зависимостей и включение правил кода над запросами LINQ (CQLinq), предназначенных для того, чтобы задать вопрос, что является сложным в моем коде и написать правило. Предусмотрено около 200 правил кода по умолчанию. Они касаются анти-паттернов, таких как Singleton, обнаружения проблем с многопоточностью, обнаружения проблем сопряжения, таких как слой пользовательского интерфейса, не должен напрямую использовать типы БД...
Некоторое время назад я написал статью, в которой резюмировал несколько аспектов сложности кода: Борьба со сфабрикованной сложностью