Sloc クロックとコード (scc)
cloc、sloccount、tokei に似たツール。多くのプログラミング言語のコード行、空白行、コメント行、およびソース コードの物理行をカウントします。
目標は、可能な限り最速のコード カウンターになることですが、sloccount などの COCOMO 計算を実行し、循環複雑度計算器と同様にコードの複雑さを推定し、独自のコード行または DRYness メトリクスを生成します。要するに、それらすべてを支配するための 1 つのツールです。
また、 sccと入力しやすい非常に短い名前を持っています。
sloc cloc と code が気に入らない場合は、 Succinct Code Counterという名前を自由に使用してください。
MITライセンスに基づいてライセンスされています。
目次
サポート
インストール
背景
ピッチ
使用法
複雑さの推定
ユニークなコード行数 (ULOC)
ココモ
出力フォーマット
パフォーマンス
発達
言語の追加/変更
問題
バッジ (ベータ版)
言語サポート
サポート
scc商業的に使用しますか? sccの優先サポートが必要な場合は、https://boyter.gumroad.com/l/kgenuv を 1 年分購入すると、開発者からの優先的な直接電子メール サポートを受けることができます。
インストール
インストールに行く
標準の go ツールチェーンを使用してsccインストールできます。
scc の最新の安定バージョンをインストールするには:
go install github.com/boyter/scc/v3@latest
開発バージョンをインストールするには:
go install github.com/boyter/scc/v3@master
sccは go バージョン 1.22 以上が必要であることに注意してください。
スナップ
Ricardo のおかげでスナップ インストールが存在します。
$ sudo snap install scc
注意Snap がインストールされたアプリケーションは/home https://askubuntu.com/questions/930437/permission-denied-error-when-running-apps-installed-as-snap-packages-ubuntu-17 の外部では実行できないため、問題が発生する可能性があります。スナップを使用し、このディレクトリの外で実行しようとした場合。
自作
または、Homebrew がインストールされている場合
$ brew install scc
Macポート
macOS では、MacPorts 経由でインストールすることもできます
$ sudo port install scc
スクープ
または、Windows で Scoop を使用している場合
$ scoop install scc
チョコレートティ
または、Windows で Chocolatey を使用している場合
$ choco install scc
ウィンゲット
または Windows で WinGet を使用している場合
winget install --id benboyter.scc --source winget
FreeBSD
FreeBSD では、scc がパッケージとして利用可能です
$ pkg install scc
または、ソースからビルドする場合は、ポート ツリーを使用できます。
$ cd /usr/ports/devel/scc && make install clean
Dockerで実行する
scc を実行するディレクトリに移動します。
以下のコマンドを実行して、現在の作業ディレクトリで scc の最新リリースを実行します。
docker run --rm -it -v "$PWD:/pwd" ghcr.io/lhoupert/scc:master scc /pwd
マニュアル
i386 マシンと x86_64 マシンの両方に対応する Windows、GNU/Linux、macOS のバイナリは、リリース ページから入手できます。
GitLab
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
他の
scc apt/chocolatey/etc に追加するのを支援したい場合は、PR を送信するか、少なくとも手順を含めて問題を提起してください。
背景
パフォーマンス ベンチマークとともにその誕生の経緯をすべて読んでください。
https://boyter.org/posts/sloc-cloc-code/
https://boyter.org/posts/why-count-lines-of-code/
https://boyter.org/posts/sloc-cloc-code-revisited/
https://boyter.org/posts/sloc-cloc-code-performance/
https://boyter.org/posts/sloc-cloc-code-performance-update/
sccのいくつかのレビュー
https://nickmchardy.com/2018/10/counting-lines-of-code-in-koi-cms.html
https://www.feliciano.tech/blog/determine-source-code-size-and-complexity-with-scc/
https://metaredux.com/posts/2019/12/13/counting-lines.html
最初の GopherCon AU で行われたsccに関する講演 (スピーカー ノートを表示するには S を押してください)
パフォーマンスについては、「パフォーマンス」セクションを参照してください。
他の同様のプロジェクト、
SLOCCount 元の sloc カウンタ
cloc、SLOCCount からインスピレーションを得たもの。移植性を高めるために Perl で実装
gocloc tokei からインスピレーションを得た Go の sloc カウンター
loc Rustの実装はtokeiに似ていますが、多くの場合より高速です
loccount Go 実装は ESR によって記述および保守されます
ポリグロット ATS sloc カウンタ
tokei は速く、正確で、Rust で書かれています
sloc CoffeeScript コードカウンター
パフォーマンスに重点を置いた新しい Go コード カウンター
他のコードカウントプロジェクト tokei、loc、polyglot、loccount に関する興味深い読み物
https://www.reddit.com/r/rust/comments/59bm3t/a_fast_cloc_replacement_in_rust/
https://www.reddit.com/r/rust/comments/82k9iy/loc_count_lines_of_code_quickly/
http://blog.vmchale.com/article/polyglot-comparisons
http://esr.ibiblio.org/?p=8270
ディスク上のファイルの処理パフォーマンスに関する詳細情報
sccを使用して GitHub/Bitbucket/GitLab からの 40 TB のファイルを処理する
ピッチ
なぜsccを使うのか？
非常に高速であり、CPU を投入するほど高速になります。
正確な
複数のプラットフォームで速度が低下することなく非常にうまく動作します (Windows、Linux、macOS)
豊富な言語サポート
重複ファイルを無視できます
複雑さの推定がある
同じディレクトリ内の Coq と Verilog の違いを区別する必要があります
cloc yaml 出力のサポートのため、一部のユーザーの代わりとなる可能性があります
縮小されたファイルを識別または無視できる
多くの # を識別できる!ファイルは進化しました! #115
大きなファイルを行単位またはバイト単位で無視できる
ファイル、言語、またはプロジェクトごとに ULOC または固有のコード行を計算できます
CSV、SQL、JSON、HTML などの統合用の複数の出力形式をサポート
なぜscc使わないのでしょうか？
違い
sccと他のツールとの間には、いくつかの重要な違いがあります。ここでは、考慮すべき重要な点をいくつか紹介します。
コメント内の空行もコメントとしてカウントされます。この行は技術的には空白ですが、コメントに入ると、そのコメントが終了するまで、そこにあるすべてのものをコメントとみなされるべきであるという決定が下されました。したがって、以下のように、
/* blank lines follow
*/
コメントは 4 行としてカウントされます。これは、scc の出力を大規模なリポジトリ上の他のツールと比較すると顕著です。
scc逐語的な文字列を正確にカウントできます。たとえば、C# では次のようになります。
private const string BasePath = @"a:";
// The below is returned to the user as a version
private const string Version = "1.0.0";
プレフィックス @ が付いているため、この文字列はエスケープ文字を無視して末尾の " で終了するため、2 コード行と 1 コメントとしてカウントされる必要があります。一部のツールはこれに対処できず、代わりに「1.0.0」までカウントします。文字列として指定すると、中央のコメントがコメントではなくコードとしてカウントされる可能性があります。
scc 、処理したバイト数 (ほとんどの出力形式の場合) も通知するので、一部の静的分析ツールの実行コストを見積もることができます。
使用法
sccのコマンド ラインの使用法は、できるだけ簡単になるように設計されています。詳細については、 scc --helpまたはscc -hを参照してください。以下にリストされている機能がインストールに含まれていない可能性があるため、以下はリリースではなくマスターの状態を反映していることに注意してください。
Sloc, Cloc and Code. Count lines of code in a directory with complexity estimation.
Version 3.5.0 (beta)
Ben Boyter + Contributors
Usage:
scc [flags] [files or directories]
Flags:
--avg-wage int average wage value used for basic COCOMO calculation (default 56286)
--binary disable binary file detection
--by-file display output for every file
-m, --character calculate max and mean characters per line
--ci enable CI output settings where stdout is ASCII
--cocomo-project-type string change COCOMO model type [organic, semi-detached, embedded, "custom,1,1,1,1"] (default "organic")
--count-as string count extension as language [e.g. jsp:htm,chead:"C Header" maps extension jsp to html and chead to C Header]
--count-ignore set to allow .gitignore and .ignore files to be counted
--currency-symbol string set currency symbol (default "$")
--debug enable debug output
--directory-walker-job-workers int controls the maximum number of workers which will walk the directory tree (default 8)
-a, --dryness calculate the DRYness of the project (implies --uloc)
--eaf float the effort adjustment factor derived from the cost drivers (1.0 if rated nominal) (default 1)
--exclude-dir strings directories to exclude (default [.git,.hg,.svn])
-x, --exclude-ext strings ignore file extensions (overrides include-ext) [comma separated list: e.g. go,java,js]
-n, --exclude-file strings ignore files with matching names (default [package-lock.json,Cargo.lock,yarn.lock,pubspec.lock,Podfile.lock,pnpm-lock.yaml])
--file-gc-count int number of files to parse before turning the GC on (default 10000)
--file-list-queue-size int the size of the queue of files found and ready to be read into memory (default 8)
--file-process-job-workers int number of goroutine workers that process files collecting stats (default 8)
--file-summary-job-queue-size int the size of the queue used to hold processed file statistics before formatting (default 8)
-f, --format string set output format [tabular, wide, json, json2, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetrics] (default "tabular")
--format-multi string have multiple format output overriding --format [e.g. tabular:stdout,csv:file.csv,json:file.json]
--gen identify generated files
--generated-markers strings string markers in head of generated files (default [do not edit,])
-h, --help help for scc
-i, --include-ext strings limit to file extensions [comma separated list: e.g. go,java,js]
--include-symlinks if set will count symlink files
-l, --languages print supported languages and extensions
--large-byte-count int number of bytes a file can contain before being removed from output (default 1000000)
--large-line-count int number of lines a file can contain before being removed from output (default 40000)
--min identify minified files
-z, --min-gen identify minified or generated files
--min-gen-line-length int number of bytes per average line for file to be considered minified or generated (default 255)
--no-cocomo remove COCOMO calculation output
-c, --no-complexity skip calculation of code complexity
-d, --no-duplicates remove duplicate files from stats and output
--no-gen ignore generated files in output (implies --gen)
--no-gitignore disables .gitignore file logic
--no-gitmodule disables .gitmodules file logic
--no-hborder remove horizontal borders between sections
--no-ignore disables .ignore file logic
--no-large ignore files over certain byte and line size set by large-line-count and large-byte-count
--no-min ignore minified files in output (implies --min)
--no-min-gen ignore minified or generated files in output (implies --min-gen)
--no-scc-ignore disables .sccignore file logic
--no-size remove size calculation output
-M, --not-match stringArray ignore files and directories matching regular expression
-o, --output string output filename (default stdout)
--overhead float set the overhead multiplier for corporate overhead (facilities, equipment, accounting, etc.) (default 2.4)
-p, --percent include percentage values in output
--remap-all string inspect every file and remap by checking for a string and remapping the language [e.g. "-*- C++ -*-":"C Header"]
--remap-unknown string inspect files of unknown type and remap by checking for a string and remapping the language [e.g. "-*- C++ -*-":"C Header"]
--size-unit string set size unit [si, binary, mixed, xkcd-kb, xkcd-kelly, xkcd-imaginary, xkcd-intel, xkcd-drive, xkcd-bakers] (default "si")
--sloccount-format print a more SLOCCount like COCOMO calculation
-s, --sort string column to sort by [files, name, lines, blanks, code, comments, complexity] (default "files")
--sql-project string use supplied name as the project identifier for the current run. Only valid with the --format sql or sql-insert option
-t, --trace enable trace output (not recommended when processing multiple files)
-u, --uloc calculate the number of unique lines of code (ULOC) for the project
-v, --verbose verbose output
--version version for scc
-w, --wide wider output with additional statistics (implies --complexity)
Redis プロジェクトの出力は以下のようになります。
$ scc redis
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
C 296 180267 20367 31679 128221 32548
C Header 215 32362 3624 6968 21770 1636
TCL 143 28959 3130 1784 24045 2340
Shell 44 1658 222 326 1110 187
Autoconf 22 10871 1038 1326 8507 953
Lua 20 525 68 70 387 65
Markdown 16 2595 683 0 1912 0
Makefile 11 1363 262 125 976 59
Ruby 10 795 78 78 639 116
gitignore 10 162 16 0 146 0
YAML 6 711 46 8 657 0
HTML 5 9658 2928 12 6718 0
C++ 4 286 48 14 224 31
License 4 100 20 0 80 0
Plain Text 3 185 26 0 159 0
CMake 2 214 43 3 168 4
CSS 2 107 16 0 91 0
Python 2 219 12 6 201 34
Systemd 2 80 6 0 74 0
BASH 1 118 14 5 99 31
Batch 1 28 2 0 26 3
C++ Header 1 9 1 3 5 0
Extensible Styleshe… 1 10 0 0 10 0
Smarty Template 1 44 1 0 43 5
m4 1 562 116 53 393 0
───────────────────────────────────────────────────────────────────────────────
Total 823 271888 32767 42460 196661 38012
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $6,918,301
Estimated Schedule Effort (organic) 28.682292 months
Estimated People Required (organic) 21.428982
───────────────────────────────────────────────────────────────────────────────
Processed 9425137 bytes, 9.425 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
実行対象のディレクトリを指定する必要はないことに注意してください。 scc実行すると、現在のディレクトリに対して実行すると想定されます。
複数のファイルまたはディレクトリscc directory1 directory2 file1 file2に対して実行し、結果を出力に集約することもできます。
scc標準出力に書き込むため、結果を簡単に共有する方法がたくさんあります。たとえば、netcat と多くのペーストビンの 1 つを使用すると、パブリック URL が得られます。
$ scc | nc paste.c-net.org 9999
https://paste.c-net.org/Example
ファイルを無視する
scc主に、スキャンするディレクトリ内の .ignore ファイルをサポートします。これは、ripgrep、ag、tokei の動作と似ています。 .ignore ファイルは、同じ構文を持つ .gitignore ファイルと 100% 同一であるため、 sccそこにリストされているファイルとディレクトリを無視します。 .ignore ファイルを追加すると、ファイルなどでチェックインされたベンダーの依存関係などを無視できます。このアイデアは、ファイルまたはフォルダーを git に追加しても、カウントでは無視できるようにするというものです。
ripgrep、ag、tokei などにサポートさせながらsccに無視させたい場合は、独自の無視ファイル.sccignoreもサポートします。
興味深い使用例
リビジョン間のコード変更を追跡するために Intel Nemu ハイパーバイザー内で使用されます https://github.com/intel/nemu/blob/topic/virt-x86/tools/cloc-change.sh#L9 両方の http:/ 内でも使用されるようです/codescoop.com/ https://pinpoint.com/ https://github.com/chaoss/grimoirelab-graal
また、https://searchcode.com/ でコードをカウントし、言語の種類を推測するためにも使用されるため、世界で最も頻繁に実行されるコード カウンターの 1 つとなっています。
scc を gitlab パイプラインにフックすることもできます https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-scc
CodeQL #317 と Scaleway でも使用されています https://twitter.com/Scaleway/status/1488087029476995074?s=20&t=N2-z6O-ISDdDzULg4o4uVQ
特徴
sccコードが改行nに到達したときにコードがどのような状態であるかを判断するために、小さなステート マシンを使用します。したがって、それは認識しており、数を数えることができます
単一行のコメント
複数行のコメント
文字列
複数行の文字列
空白行
このため、コメントが文字列内にあるのか、それとも実際にコメントであるのかを正確に判断できます。
また、コードの複雑さをカウントしようとします。これは、コード内の分岐操作をチェックすることによって行われます。たとえば、次の各for if switch while else || && != ==が Java で発生した場合、そのファイルの複雑さは 1 つ増加します。
複雑さの推定
複雑さの見積もり自体について少し説明しましょう。
複雑さの推定値は実際には、同じ言語のファイルとのみ比較できる単なる数値です。言語を重み付けせずに直接比較するために使用しないでください。その理由は、コード内の分岐ステートメントとループ ステートメントを検索し、そのファイルのカウンターをインクリメントすることによって計算されるためです。
一部の言語にはループがなく、代わりに再帰が使用されるため、複雑さのカウントが低くなります。これは、それほど複雑ではないことを意味しますか?おそらくそうではありませんが、ツールはコードをスキャンするだけでコードの AST を構築しないため、これを認識できません。
一般に、複雑さは、同じ言語で書かれたプロジェクト間で推定したり、プロジェクト内で最も複雑なファイルを見つけるのに役立ちます。 scc --by-file -s complexity 、何かがどれだけ難しいかを推定するときに役立ちます。メンテナンスするとき、またはおそらくリファクタリングする必要があるファイルを探すとき。
それがどのように機能するかについては。
これは私自身の定義ですが、ファイル レベルでのみ行われますが、循環的複雑さ https://en.wikipedia.org/wiki/Cyclomatic_complexity の近似になるように努めています。
これが近似値である理由は、実際の循環的複雑度のカウントではコードを解析する必要があるのに対し、CPU の観点からはほぼ無料で計算されるためです (カウントする際の検索が安価であるため)。たとえ再帰的メソッドを特定できなかったとしても、実際には合理的な推測が得られます。目標は決して正確なものではありませんでした。
つまり、scc がコードとして識別したものを調べているときに、通常は分岐条件であることに気付いた場合、カウンターをインクリメントします。
検索する条件はコードにコンパイルされており、リポジトリ内の JSON を見ることで条件を把握できます。 Java のファイルを検索する例については、https://github.com/boyter/scc/blob/master/langages.json#L3869 を参照してください。
増分は一致する条件ごとに発生し、表示される数値が生成されます。
ユニークなコード行数 (ULOC)
ULOC は Unique Lines of Code の略で、言語、ファイル、プロジェクト自体にわたる固有の行を表します。このアイデアは https://cmcenroe.me/2018/12/14/uloc.html から引用したもので、計算は標準 Unix ツールsort -u *.h *.c | wc -lを使用して表示されます。 sort -u *.h *.c | wc -l 。このメトリクスは、プロジェクト内の複雑さの推定を支援するためにあります。出典を引用すると
私の意見では、これによって生成される数値は、プロジェクトの複雑さをより適切に推定できるはずです。 SLOC と比較すると、空白行だけでなく、中括弧行や、一般的なインクルードなどのその他の繰り返しコードも割引されます。一方、ULOC は、その周囲のコードと同じくらい多くのメンテナンスを必要とするコメントをカウントしますが、たとえば、すべてのファイルに表示されるライセンス ヘッダーによる結果の増大を回避します。
ULOC を取得するには、 -uまたは--uloc引数をsccに指定します。
これには、CLOC に対する ULOC の割合、またはDRYness = ULOC / SLOCである、対応するメトリックDRYness %があります。数値が大きいほど、プロジェクトはより DRY (同じことを繰り返さない) と考えられます。一般に、ここでの値が高いほど、コードの重複が少ないことを示すため、より優れています。 DRYness 指標は、minimax のコメント https://lobste.rs/s/has9r7/uloc_unique_lines_code から取得されました。
DRYness メトリックを取得するには、 sccに-aまたは--dryness引数を使用します。これにより、暗黙的に--uloc設定されます。
ULOC メトリクスを計算するときにパフォーマンスが低下し、実行時間が 2 倍になる可能性があることに注意してください。
C コードに対して uloc および DRYness の計算を実行すると、redis のクローンが次のような出力を生成します。
$ scc -a -i c redis
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
C 419 241293 27309 41292 172692 40849
(ULOC) 133535
───────────────────────────────────────────────────────────────────────────────
Total 419 241293 27309 41292 172692 40849
───────────────────────────────────────────────────────────────────────────────
Unique Lines of Code (ULOC) 133535
DRYness % 0.55
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $6,035,748
Estimated Schedule Effort (organic) 27.23 months
Estimated People Required (organic) 19.69
───────────────────────────────────────────────────────────────────────────────
Processed 8407821 bytes, 8.408 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
ULOC 計算の詳細については、https://boyter.org/posts/sloc-cloc-code-new-metic-uloc/ を参照してください。
ココモ
コマンドライン実行の下部に表示される COCOMO 統計は、必要に応じて構成できます。
Estimated Cost to Develop (organic) $664,081
Estimated Schedule Effort (organic) 11.772217 months
Estimated People Required (organic) 5.011633
COCOMO パラメータを変更するには、デフォルトの COCOMO モデルのいずれかを使用できます。
scc --cocomo-project-type organic
scc --cocomo-project-type semi-detached
scc --cocomo-project-type embedded
COCOMO に精通している場合は、次のように独自のパラメータを指定することもできます。
scc --cocomo-project-type "custom,1,1,1,1"
モデルの選択方法と使用するパラメーターの詳細については、以下を参照してください。
有機的 – 必要なチームの規模が適切に小さく、問題がよく理解され過去に解決されており、チーム メンバーが問題に関してわずかな経験を持っている場合、ソフトウェア プロジェクトは有機的タイプであると言われます。
scc --cocomo-project-type "organic,2.4,1.05,2.5,0.38"
セミデタッチ – チームの規模、経験、さまざまなプログラミング環境の知識などの重要な特性がオーガニックと組み込みの中間にあるソフトウェア プロジェクトは、セミデタッチ タイプと言われます。 Semi-Detached として分類されるプロジェクトは、Organic プロジェクトに比べて比較的馴染みが薄く、開発が難しく、より多くの経験と、より優れた指導と創造性が必要とされます。例: コンパイラまたはさまざまな組み込みシステムは、セミデタッチ型と考えることができます。
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
組み込み – 最高レベルの複雑さ、創造性、経験要件を必要とするソフトウェア プロジェクトがこのカテゴリに分類されます。このようなソフトウェアでは、他の 2 つのモデルよりも大きなチーム サイズが必要であり、開発者には、このような複雑なモデルを開発するのに十分な経験と創造性が必要です。
scc --cocomo-project-type "embedded,3.6,1.20,2.5,0.32"
大きなファイルの検出
scc大きなファイルを出力から除外することができます。
そのためのオプションは--no-largeで、デフォルトでは 1,000,000 バイトまたは 40,000 行を超えるファイルが除外されます。
--large-byte-countまたは--large-line-countを使用して、どちらの値のサイズも制御できます。
たとえば、1,000 行および 50kb を超えるファイルを除外するには、次のように使用できます。
scc --no-large --large-byte-count 50000 --large-line-count 1000
縮小/生成されたファイルの検出
sccに、縮小されたファイルまたは出力から生成されたファイルを識別させ、オプションで削除させることができます。
これを行うには、 scc -zのように-zフラグを有効にすることで、平均行バイト サイズが 255 (デフォルト) 以上のファイルを縮小対象として識別します。
縮小されたファイルは出力に次のように表示されます。
$ scc --no-cocomo -z ./examples/minified/jquery-3.1.1.min.js
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
JavaScript (min) 1 4 0 1 3 17
───────────────────────────────────────────────────────────────────────────────
Total 1 4 0 1 3 17
───────────────────────────────────────────────────────────────────────────────
Processed 86709 bytes, 0.087 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
縮小されたファイルは、言語名の後のテキスト(min)で示されます。
生成されたファイルは、言語名の後にテキスト(gen)が付きます。
scc -z --min-gen-line-length 1などの--min-gen-line-lengthを使用して、行の平均バイト サイズを制御できます。この値を変更しても検出が縮小されるわけではないため、 -z必要であることに注意してください。
--no-min-genフラグを使用すると、縮小されたファイルをカウントから完全に除外できます。縮小チェックに一致するファイルは出力から除外されます。
再マッピング
ファイルによっては拡張子がない場合があります。 #! であるかどうかがチェックされます。ファイル。そうである場合、言語は正しい言語に再マッピングされます。それ以外の場合は処理されません。
ただし、そのようなファイルをファイル内の文字列に基づいて再マップする必要がある場合もあります。これを行うには、 --remap-unknownを使用できます
scc --remap-unknown "-*- C++ -*-":"C Header"
上記は、拡張子のないファイルを検査して文字列-*- C++ -*-を探し、見つかった場合は、C ヘッダー ルールを使用してカウントされるファイルを再マップします。必要に応じて、複数のリマップ ルールを設定できます。
scc --remap-unknown "-*- C++ -*-":"C Header","other":"Java"
すべてのファイルを再マップする--remap-allパラメーターもあります。
どのような場合でも、リマップ ルールが通常の #! を適用しないことに注意してください。ルールが適用されます。
出力フォーマット
デフォルトでは、 sccコンソールに出力します。ただし、必要に応じて、他の形式で出力を生成できます。
さまざまなオプションはtabular, wide, json, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetricsです。
-o, --outputオプションを使用して、 scc出力をディスクに書き込むことができることに注意してください。これにより、出力を書き込むファイルを指定できます。たとえば、 scc -f html -o output.html現在のディレクトリに対してsccを実行し、結果を html 形式でファイルoutput.htmlに出力します。
--format-multiオプションを使用したい場合は、複数の出力ファイルに書き込んだり、複数のタイプを stdout に書き込んだりすることもできます。これは、標準出力にカウントも表示しながら、成果物として HTML レポートを必要とする CI/CD システムで作業する場合に最も役立ちます。
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
上記は現在のディレクトリに対して実行され、デフォルトの出力を標準出力に出力するだけでなく、適切な形式でoutput.htmlとoutput.csvに書き込みます。
表形式
これは、scc を実行するときのデフォルトの出力形式です。
広い
Wide では、複雑さ/行数のメトリックである追加情報が生成されます。これは、複雑さの推定に基づいてプロジェクト内で最も複雑なファイルを特定する場合に役立ちます。
JSON
JSON は JSON 出力を生成します。主に、 scc他のプログラムにフィードできるように設計されています。
この形式により、 scc読み取るすべてのファイルのバイト サイズが得られ、処理されたバイト数の内訳を取得できることに注意してください。
CSV
オプションとしての CSV は、分析のためにスプレッドシートにインポートするのに適しています。
この形式により、 scc読み取るすべてのファイルのバイト サイズが得られ、処理されたバイト数の内訳を取得できることに注意してください。また、CSV は--by-file尊重するため、デフォルトで概要を返すことにも注意してください。
CSVストリーム
csv-stream は、メモリの問題が発生する可能性が高い非常に大規模なリポジトリを処理する場合に役立つオプションです。出力形式はCSVと100%同じです。
これをformat-multiオプションと一緒に使用しないでください。これは常に標準出力に出力され、その動作方法により、通常得られるメモリの節約が無効になるためです。このオプションにより節約が可能になります。このオプションでは並べ替えは適用されないことに注意してください。
クロックヤムル
yaml 出力オプションを使用する cloc のドロップイン代替品です。これは他のビルド システムに渡すためによく使用され、必要に応じて cloc を置き換えるのに役立ちます。
$ scc -f cloc-yml processor
# https://github.com/boyter/scc/
header:
url: https://github.com/boyter/scc/
version: 2.11.0
elapsed_seconds: 0.008
n_files: 21
n_lines: 6562
files_per_second: 2625
lines_per_second: 820250
Go:
name: Go
code: 5186
comment: 273
blank: 1103
nFiles: 21
SUM:
code: 5186
comment: 273
blank: 1103
nFiles: 21
$ cloc --yaml processor
21 text files.
21 unique files.
0 files ignored.
---
# http://cloc.sourceforge.net
header :
cloc_url : http://cloc.sourceforge.net
cloc_version : 1.60
elapsed_seconds : 0.196972846984863
n_files : 21
n_lines : 6562
files_per_second : 106.613679608407
lines_per_second : 33314.2364566841
Go:
nFiles: 21
blank: 1137
comment: 606
code: 4819
SUM:
blank: 1137
code: 4819
comment: 606
nFiles: 21
HTML と HTML-TABLE
HTML 出力オプションは、スタンドアロンhtmlであるテーブル、または独自の HTML ページに挿入できる単なるテーブルhtml-tableとしてテーブルを使用して、最小限の HTML レポートを生成します。 2 つの唯一の違いは、 htmlオプションには最小限のスタイルを備えた HTML head タグと body タグが含まれることです。
マークアップは、独自のカスタム スタイルを適用できるように設計されています。レポートの例はここでご覧いただけます。
HTML オプションはコマンド ライン オプションの後に続くため、 scc --by-file -f html使用すると、概要だけでなくすべてのファイルを含むレポートを作成できることに注意してください。
この形式に--by-fileオプションがある場合、 scc読み取るすべてのファイルのバイト サイズが得られるため、処理されたバイト数の内訳を取得できることに注意してください。
SQL と SQL-Insert
SQL 出力形式は cloc の SQL 出力形式と「ほぼ」互換性があります https://github.com/AlDanial/cloc#sql-
cloc ドキュメントのすべてのクエリは期待どおりに動作するはずですが、 sccとclocからの出力を同じデータベースに追加することはできません。これは、複雑さのカウントやバイト数などの scc を考慮してテーブルの形式が若干異なるためです。
sqlとsql-insertの違いは、 sqlはテーブルの作成が含まれるのに対し、後者には挿入コマンドのみがあることです。
使用法は他のsccコマンドと 100% 同じですが、SQL 出力には常にファイルごとの詳細が含まれます。 SQL を使用して合計を自分で計算することもできますが、COCOMO の計算は、
