cloc, sloccount 및 tokei와 유사한 도구입니다. 많은 프로그래밍 언어에서 코드 줄, 빈 줄, 주석 줄 및 소스 코드의 물리적 줄을 계산합니다.
목표는 가능한 가장 빠른 코드 카운터가 되는 동시에 sloccount와 같은 COCOMO 계산을 수행하고 순환 복잡도 계산기와 유사한 코드 복잡도를 추정하며 고유한 코드 줄 또는 DRYness 메트릭을 생성하는 것입니다. 간단히 말해서 모든 것을 지배하는 하나의 도구입니다.
또한 scc
입력하기 쉬운 매우 짧은 이름을 가지고 있습니다.
sloc cloc 및 코드가 마음에 들지 않으면 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
에는 버전 >= 1.22가 필요합니다.
Ricardo 덕분에 스냅 설치가 가능합니다.
$ sudo snap install scc
NB Snap이 설치된 애플리케이션은 /home
https://askubuntu.com/questions/930437/permission-denied-error-when-running-apps-installed-as-snap-packages-ubuntu-17 외부에서 실행할 수 없으므로 문제가 발생할 수 있습니다. snap을 사용하고 이 디렉터리 외부에서 실행을 시도하는 경우.
또는 Homebrew가 설치되어 있는 경우
$ brew install scc
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에서는 scc를 패키지로 사용할 수 있습니다.
$ pkg install scc
또는 소스에서 빌드하려는 경우 포트 트리를 사용할 수 있습니다.
$ cd /usr/ports/devel/scc && make install clean
scc를 실행하려는 디렉터리로 이동합니다.
현재 작업 디렉터리에서 최신 scc 릴리스를 실행하려면 아래 명령을 실행하세요.
docker run --rm -it -v "$PWD:/pwd" ghcr.io/lhoupert/scc:master scc /pwd
i386 및 x86_64 시스템 모두에 대한 Windows, GNU/Linux 및 macOS용 바이너리는 릴리스 페이지에서 사용할 수 있습니다.
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
apt/chocolatey/etc에 scc
추가하는 데 도움을 주고 싶다면 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를 누르세요)
https://boyter.org/static/gophercon-syd-presentation/
https://www.youtube.com/watch?v=jd-sjoy3GZo
성능에 대해서는 성능 섹션을 참조하세요.
기타 유사한 프로젝트,
SLOCCount 원래 sloc 카운터
SLOCCount에서 영감을 받은 cloc; 이식성을 위해 Perl로 구현됨
gocloc tokei에서 영감을 받은 Go의 sloc 카운터
loc Rust 구현은 tokei와 유사하지만 종종 더 빠릅니다.
loccount ESR이 작성하고 유지 관리하는 Go 구현
다중 언어 ATS sloc 카운터
tokei 빠르고 정확하며 녹으로 작성됨
sloc 커피스크립트 코드 카운터
성능에 초점을 맞춘 새로운 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
디스크 성능에 따른 파일 처리에 대한 추가 정보
https://blog.burntsushi.net/ripgrep/
scc
사용하여 GitHub/Bitbucket/GitLab에서 40TB의 파일 처리
https://boyter.org/posts/an-informal-survey-of-10-million-github-bitbucket-gitlab-projects/
왜 scc
사용하나요?
매우 빠르고 더 많은 CPU를 사용할수록 더 빨라집니다.
정확한
속도 저하 없이 여러 플랫폼에서 매우 잘 작동합니다(Windows, Linux, macOS)
대규모 언어 지원
중복 파일을 무시할 수 있습니다.
복잡성 추정이 있습니다
동일한 디렉토리에 있는 Coq과 Verilog의 차이점을 알려야 합니다.
cloc yaml 출력 지원으로 일부 사용자에게는 잠재적으로 교체가 중단될 수 있습니다.
축소된 파일을 식별하거나 무시할 수 있습니다.
다수의 # 식별 가능! 파일 고급! #115
라인 또는 바이트 단위로 대용량 파일을 무시할 수 있습니다.
파일, 언어 또는 프로젝트별로 ULOC 또는 고유한 코드 줄을 계산할 수 있습니다.
통합, CSV, SQL, JSON, HTML 등을 위한 다양한 출력 형식 지원
scc
사용하지 않는 이유는 무엇입니까?
당신은 왠지 Go를 좋아하지 않습니다
서로 다른 중첩된 여러 줄 주석이 있는 D 소스를 올바르게 계산할 수 없습니다. #27
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과 많은 Pastebin 중 하나를 사용하면 공개 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/에서 코드를 계산하고 언어 유형을 추측하는 데 사용되므로 세계에서 가장 자주 실행되는 코드 카운터 중 하나입니다.
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
https://docs.linuxfoundation.org/lfx/insights/v3-beta-version-current/getting-started/landing-page/cocomo-cost-estimation-simplified
https://openems.io/
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/언어s.json#L3869를 참조하세요.
일치하는 각 조건에 대해 증가가 발생하고 표시되는 숫자를 생성합니다.
ULOC는 Unique Lines of Code의 약자로 언어, 파일 및 프로젝트 자체 전반에 걸쳐 고유한 라인을 나타냅니다. 이 아이디어는 표준 Unix 도구 sort -u *.h *.c | wc -l
. 이 측정 기준은 프로젝트 내의 복잡성을 평가하는 데 도움이 됩니다. 출처 인용
내 생각에는 이것이 생성하는 숫자가 프로젝트의 복잡성을 더 잘 추정하는 것이어야 합니다. SLOC와 비교하면 빈 줄뿐만 아니라 닫는 중괄호 줄과 공통 포함과 같은 기타 반복 코드도 할인됩니다. 반면에 ULOC는 주석을 계산합니다. 주석은 주변 코드만큼 유지 관리가 필요하며 예를 들어 모든 파일에 나타나는 라이센스 헤더로 결과가 부풀려지는 것을 방지합니다.
scc
에 -u
또는 --uloc
인수를 제공하여 ULOC를 얻을 수 있습니다.
여기에는 ULOC 대 CLOC의 비율 또는 DRYness = ULOC / SLOC
인 해당 측정항목 DRYness %
가 있습니다. 숫자가 높을수록 프로젝트가 더 DRY(반복하지 마세요)로 간주될 수 있습니다. 일반적으로 여기서 값이 높을수록 코드 중복이 적다는 것을 의미하므로 더 좋습니다. DRYness 측정항목은 minimax https://lobste.rs/s/has9r7/uloc_unique_lines_code의 댓글에서 가져왔습니다.
DRYness 지표를 얻으려면 scc
에 -a
또는 --dryness
인수를 사용할 수 있습니다. 그러면 암시적으로 --uloc
설정됩니다.
런타임을 두 배로 늘릴 수 있는 ULOC 측정항목을 계산할 때 성능 저하가 있다는 점에 유의하세요.
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)으로 분류된 프로젝트는 유기적 프로젝트에 비해 상대적으로 덜 친숙하고 개발하기 어려우며 더 많은 경험과 더 나은 지도력 및 창의성이 필요합니다. 예: 컴파일러 또는 다른 임베디드 시스템은 반 분리형으로 간주될 수 있습니다.
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
임베디드 – 최고 수준의 복잡성, 창의성 및 경험 요구 사항이 필요한 소프트웨어 프로젝트가 이 범주에 속합니다. 이러한 소프트웨어에는 다른 두 모델보다 더 큰 팀 규모가 필요하며 개발자도 이러한 복잡한 모델을 개발하려면 충분한 경험과 창의성이 필요합니다.
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 보고서를 아티팩트로 표시하는 동시에 stdout에 개수를 표시하려는 CI/CD 시스템에서 작업할 때 가장 유용합니다.
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
위의 작업은 현재 디렉터리에 대해 실행되어 기본 출력을 표준 출력으로 출력하고 적절한 형식으로 출력.html 및 출력.csv에 기록합니다.
이는 scc가 실행될 때 기본 출력 형식입니다.
Wide는 복잡성/선 측정항목인 몇 가지 추가 정보를 생성합니다. 이는 복잡성 추정을 기반으로 프로젝트 내에서 가장 복잡한 파일을 식별하려고 할 때 유용할 수 있습니다.
JSON은 JSON 출력을 생성합니다. 주로 scc
다른 프로그램에 공급될 수 있도록 설계되었습니다.
이 형식은 scc
읽는 모든 파일의 바이트 크기를 제공하므로 처리된 바이트 수를 분석할 수 있습니다.
옵션인 CSV는 분석을 위해 스프레드시트로 가져오는 데 적합합니다.
이 형식은 scc
읽는 모든 파일의 바이트 크기를 제공하므로 처리된 바이트 수를 분석할 수 있습니다. 또한 CSV는 --by-file
존중하므로 기본적으로 요약을 반환합니다.
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
테이블 또는 자신의 HTML 페이지에 삽입할 수 있는 html-table
사용하여 최소한의 HTML 보고서를 생성합니다. 둘 사이의 유일한 차이점은 html
옵션에는 최소한의 스타일로 html 헤드 및 본문 태그가 포함된다는 것입니다.
마크업은 사용자 정의 스타일을 적용할 수 있도록 설계되었습니다. 예시 보고서를 보려면 여기를 클릭하세요.
HTML 옵션은 명령줄 옵션을 따르므로 scc --by-file -f html
사용하여 요약뿐만 아니라 모든 파일이 포함된 보고서를 생성할 수 있습니다.
--by-file
옵션이 있는 경우 이 형식은 scc
읽는 모든 파일의 바이트 크기를 제공하므로 처리된 바이트 수를 분석할 수 있습니다.
SQL 출력 형식은 cloc의 SQL 출력 형식 https://github.com/AlDanial/cloc#sql-과 "대부분" 호환됩니다.
cloc 문서의 모든 쿼리는 예상대로 작동해야 하지만 scc
및 cloc
의 출력을 동일한 데이터베이스에 추가할 수는 없습니다. 이는 복잡성 수 및 바이트를 포함하여 scc를 설명하기 위해 테이블 형식이 약간 다르기 때문입니다.
sql
과 sql-insert
의 차이점은 sql
테이블 생성이 포함되고 후자에는 삽입 명령만 포함된다는 점입니다.
사용법은 다른 scc
명령과 100% 동일하지만 SQL 출력에는 항상 파일별 세부 정보가 포함됩니다. SQL을 사용하여 총계를 직접 계산할 수 있지만 COCOMO 계산은