Я хочу собрать несколько статистических данных о репозитории, чтобы сравнить их во времени. Цель состоит в том, чтобы узнать, как использование конкретных языков развивалось с течением времени, и как росли или уменьшались сложность и размер различных проектов.
Есть отличный инструмент, clocкоторый измеряет строки кода на разных языках. Это хорошее начало, но показатель LOC не очень репрезентативен. Я хотел бы собрать лучшие показатели, такие как, во-первых, логические строки кода и функциональные точки, и, наконец, цикломатическая сложность.
Для этого тоже есть инструменты:
В Python есть отличная radonбиблиотека, которая дает LLOC, цикломатическую сложность и т. д., а также позволяет косвенно определять количество функциональных точек.
C#, очевидно, имеет метрики кода Visual Studio, которые также предоставляют подробную информацию, включая ILLOC, который, в отличие от LOC, вполне репрезентативен для размера проекта, а также цикломатической сложности.
В JavaScript complexity-reportтакже есть возможность вычислить количество функциональных точек, а также LLOC и цикломатическую сложность.
У PHP, кажется, тоже есть инструмент , который дает как LLOC, так и количество функциональных точек, а также цикломатическую сложность и другую информацию.
Чего я не могу найти, так это аналогичного инструмента для Bash. Существует хорошо известный инструмент статического анализа ShellCheck , но это не то, что мне нужно: ShellCheck скорее ищет возможные проблемы с кодом, аналогично jslintанализу кода JavaScript и C#.
Так:
Есть ли инструмент, который, как и cloc, показывает LLOC, функциональные точки и цикломатическую сложность для десятков языков?
Или есть такой инструмент специально для Bash-скриптов?
Примечание. Меня интересует бесплатный инструмент, который можно использовать с терминала Linux, а не платные продукты, онлайн-сервисы или API.
[2 месяца и нет ответов. Я даю коммерческий ответ, так как других ответов не ожидается.]
Наша система поиска исходного кода (SCSE) используется для поиска интересных идиом кода в больших репозиториях, содержащих множество (возможно, десятки) языков. Это быстро, потому что индексирует кодовую базу в соответствии с лексическим синтаксисом каждого из языков; для каждого языка используется точный лексический анализатор. (Это продукт для Windows, но он специально упакован так, чтобы можно было работать с Wine, со сценариями оболочки, которые делают его похожим на Linux).
Примечательно, что побочным эффектом процесса индексирования является создание различных метрик на уровне файлов с помощью SLOC, непустых строк кода, пустых строк, цикломатической сложности и показателей Холстеда . Он не выполняет функциональные точки (вам понадобятся обратные числа для каждого языка, и тогда вы можете легко это вычислить). Показатели фактически создаются в виде XML-файла; тривиальный сценарий преобразует его в HTML-таблицу, подобную показанной.
Это будет охватывать языки в вашей кодовой базе, кроме Bash. (Не в готовом виде, но SCSE получил то, что есть, благодаря процессу определения таких лексеров, и можно было бы определить точный лексер для Bash). Тем не менее, один из доступных лексеров предназначен для чего-то, что мы называем AdhocText, который должен быть языком программирования, который вы найдете в случайной книге по компьютерному программированию, поэтому он содержит все классические лексемы, которые вы ожидаете найти в универсальном языке. Это работает лучше, чем вы могли бы ожидать на произвольном языке программирования.
Грязная проблема с большой базой кода заключается в категоризации файлов в соответствии с языками, чтобы связать каждый файл с соответствующим языковым лексером. У нас есть еще один инструмент File Inventory , который может быть указан в наборе каталогов, классифицирует файлы в соответствии с подсказками расширения и содержимого, а затем повторно проверяет классификацию, используя те же самые лексеры, которые используются SCSE. Запуск этого инструмента в основном берет совершенно неорганизованный набор каталогов, сортирует файлы по типам, идентифицирует дубликаты и генерирует файлы конфигурации для запуска SCSE.
Резюме:
Я выпустил Cyclomatic Complexity Analyzer для сценария оболочки.
ShellMetrics — цикломатический анализатор сложности для сценария оболочки
https://github.com/shellspec/shellmetrics
Он измеряет NLOC (строка кода без комментариев), LLOC (логические строки кода) и CCN (число цикломатической сложности) сценариев оболочки, включая bash.
Вот образец отчета о покрытии.
==============================================================================
LLOC CCN Location
------------------------------------------------------------------------------
1 1 usage:9 shellmetrics
...
3 1 repeat_string:73 shellmetrics
3 2 array:79 shellmetrics
2 1 array_is_empty:86 shellmetrics
7 2 push_array:91 shellmetrics
11 3 pop_array:102 shellmetrics
11 3 shift_array:119 shellmetrics
8 3 peel:136 shellmetrics
7 3 pretty:149 shellmetrics
2 1 process:162 shellmetrics
65 27 parse:167 shellmetrics
...
52 2 <main> shellmetrics
------------------------------------------------------------------------------
1 file(s), 33 function(s) analyzed. [bash 4.4.20(1)-release]
==============================================================================
NLOC NLOC LLOC LLOC CCN Func File (lines:comment:blank)
total avg total avg avg cnt
------------------------------------------------------------------------------
412 12.48 332 10.06 3.18 33 shellmetrics (479:5:62)
------------------------------------------------------------------------------
==============================================================================
NLOC NLOC LLOC LLOC CCN Func File lines comment blank
total avg total avg avg cnt cnt total total total
------------------------------------------------------------------------------
412 12.48 332 10.06 3.18 33 1 479 5 62
------------------------------------------------------------------------------
Стив Барнс
Арсений Мурзенко
clocи, что более важно, добавляет цикломатическую сложность, ему не хватает LLOC и функциональных точек. С другой стороны, мне не ясно, действительно ли LLOC более актуален, чем LOC для Bash, и функциональные точки также могут не иметь значения (например, для больших скриптов, не содержащих функций). Предлагаю подождать несколько дней других ответов, а если таковых нет, закрыть мой вопрос как дубликат.