Sloc Cloc และรหัส (scc)
เครื่องมือที่คล้ายกับ cloc, sloccount และ tokei สำหรับการนับบรรทัดของโค้ด บรรทัดว่าง บรรทัดความคิดเห็น และบรรทัดฟิสิคัลของซอร์สโค้ดในภาษาการเขียนโปรแกรมต่างๆ
เป้าหมายคือการเป็นตัวนับโค้ดที่เร็วที่สุดเท่าที่จะเป็นไปได้ แต่ยังทำการคำนวณ COCOMO เช่น sloccount ประเมินความซับซ้อนของโค้ดที่คล้ายกับเครื่องคำนวณความซับซ้อนแบบไซโคลมาติก และสร้างบรรทัดโค้ดหรือหน่วยวัด DRYness ที่ไม่ซ้ำใคร กล่าวโดยย่อคือเครื่องมือเดียวที่จะควบคุมพวกเขาทั้งหมด
นอกจากนี้ยังมีชื่อที่สั้นมากซึ่งง่ายต่อการพิมพ์ scc
หากคุณไม่ชอบ sloc cloc และโค้ด คุณสามารถใช้ชื่อ Succinct Code Counter ได้
ได้รับอนุญาตภายใต้ใบอนุญาต MIT
สารบัญ
สนับสนุน
ติดตั้ง
พื้นหลัง
ขว้าง
การใช้งาน
การประมาณความซับซ้อน
บรรทัดรหัสเฉพาะ (ULOC)
โคโคโม
รูปแบบเอาต์พุต
ผลงาน
การพัฒนา
การเพิ่ม/แก้ไขภาษา
ปัญหา
ป้าย (เบต้า)
รองรับภาษา
สนับสนุน
ใช้ scc ในเชิงพาณิชย์หรือไม่ หากคุณต้องการการสนับสนุนตามลำดับความสำคัญสำหรับ scc คุณสามารถซื้อปีมูลค่า https://boyter.gumroad.com/l/kgenuv ซึ่งให้สิทธิ์คุณรับการสนับสนุนทางอีเมลโดยตรงตามลำดับความสำคัญจากนักพัฒนา
ติดตั้ง
ไปติดตั้ง
คุณสามารถติดตั้ง scc ได้โดยใช้ toolchain go มาตรฐาน
หากต้องการติดตั้ง scc เวอร์ชันเสถียรล่าสุด:
go install github.com/boyter/scc/v3@latest
ในการติดตั้งเวอร์ชันการพัฒนา:
go install github.com/boyter/scc/v3@master
โปรดทราบว่า scc ต้องใช้เวอร์ชัน go >= 1.22
สแน็ป
มีการติดตั้ง snap ต้องขอบคุณ 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
ตัก
หรือหากคุณใช้ Scoop บน Windows
$ scoop install scc
ช็อคโกแลต
หรือถ้าคุณใช้ Chocolatey บน Windows
$ choco install scc
วินเก็ต
หรือถ้าคุณใช้ WinGet บน Windows
winget install --id benboyter.scc --source winget
ฟรีBSD
บน 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
คู่มือ
ไบนารีสำหรับ Windows, GNU/Linux และ macOS สำหรับทั้งเครื่อง i386 และ x86_64 มีอยู่ในหน้าเผยแพร่
GitLab
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
อื่น
หากคุณต้องการช่วยเพิ่ม scc ลงใน apt/chocolatey/etc... โปรดส่งประชาสัมพันธ์หรืออย่างน้อยก็แจ้งปัญหาพร้อมคำแนะนำ
พื้นหลัง
อ่านทั้งหมดเกี่ยวกับวิธีการที่มันมาพร้อมกับการวัดประสิทธิภาพ
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 เพื่อดูบันทึกของผู้บรรยาย)
สำหรับประสิทธิภาพ โปรดดูส่วนประสิทธิภาพ
โครงการอื่นที่คล้ายคลึงกัน
SLOCนับตัวนับ sloc ดั้งเดิม
cloc ได้รับแรงบันดาลใจจาก SLOCCount; นำไปใช้ใน Perl เพื่อการพกพา
gocloc ตัวนับ sloc ใน Go ที่ได้รับแรงบันดาลใจจาก tokei
การใช้ locrust คล้ายกับ tokei แต่มักจะเร็วกว่า
การใช้งาน loccount Go เขียนและดูแลรักษาโดย ESR
พูดได้หลายภาษา ATS sloc counter
tokei รวดเร็ว แม่นยำ และเขียนด้วยสนิม
ตัวนับรหัส sloc coffeescript
stto ตัวนับโค้ด 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 เพื่อประมวลผลไฟล์ขนาด 40 TB จาก GitHub/Bitbucket/GitLab
ขว้าง
ทำไมต้องใช้ 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 และหนึ่งในหลายๆ pastebins จะให้ URL สาธารณะ:
$ scc | nc paste.c-net.org 9999
https://paste.c-net.org/Example
ละเว้นไฟล์
scc ส่วนใหญ่รองรับไฟล์ .ignore ภายในไดเร็กทอรีที่สแกน สิ่งนี้คล้ายกับวิธีการทำงานของ ripgrep, ag และ tokei ไฟล์ .ignore นั้นเหมือนกับไฟล์ .gitignore ที่มีไวยากรณ์เหมือนกัน 100% และด้วยเหตุนี้ scc จะไม่สนใจไฟล์และไดเร็กทอรีที่อยู่ในรายการ คุณสามารถเพิ่มไฟล์ .ignore เพื่อละเว้นสิ่งต่าง ๆ เช่น การพึ่งพาผู้ขายที่ตรวจสอบในไฟล์และอื่น ๆ แนวคิดนี้คือการอนุญาตให้คุณเพิ่มไฟล์หรือโฟลเดอร์เพื่อคอมไพล์และไม่ต้องสนใจในการนับ
นอกจากนี้ยังรองรับไฟล์ละเว้นของตัวเอง .sccignore หากคุณต้องการให้ scc เพิกเฉยต่อสิ่งต่าง ๆ ในขณะที่มี ripgrep, ag, tokei และผู้อื่นสนับสนุน
กรณีการใช้งานที่น่าสนใจ
ใช้ภายใน Intel Nemu Hypervisor เพื่อติดตามการเปลี่ยนแปลงโค้ดระหว่างการแก้ไข 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
คุณสมบัติ
scc ใช้เครื่องสถานะขนาดเล็กเพื่อกำหนดสถานะรหัสเมื่อถึงบรรทัดใหม่ n จึงทราบและสามารถนับได้
ความคิดเห็นบรรทัดเดียว
ความคิดเห็นหลายบรรทัด
สตริง
สตริงหลายบรรทัด
เส้นว่าง
ด้วยเหตุนี้จึงสามารถระบุได้อย่างถูกต้องว่าความคิดเห็นอยู่ในสตริงหรือเป็นความคิดเห็นจริงๆ
นอกจากนี้ยังพยายามนับความซับซ้อนของโค้ดด้วย ซึ่งทำได้โดยการตรวจสอบการดำเนินการแยกสาขาในโค้ด ตัวอย่างเช่น แต่ละค่าต่อไปนี้ for if switch while else || && != == หากพบใน Java ความซับซ้อนของไฟล์นั้นจะเพิ่มขึ้นหนึ่งรายการ
การประมาณความซับซ้อน
เราใช้เวลาสักครู่เพื่อหารือเกี่ยวกับการประมาณความซับซ้อนของตัวเอง
การประมาณความซับซ้อนเป็นเพียงตัวเลขที่สามารถเทียบเคียงได้กับไฟล์ในภาษาเดียวกันเท่านั้น ไม่ควรใช้เพื่อเปรียบเทียบภาษาโดยตรงโดยไม่ถ่วงน้ำหนัก เหตุผลก็คือ คำนวณโดยการมองหาคำสั่งสาขาและคำสั่งวนซ้ำในโค้ดและเพิ่มตัวนับสำหรับไฟล์นั้น
เนื่องจากบางภาษาไม่มีการวนซ้ำและใช้การเรียกซ้ำแทน จึงทำให้มีจำนวนความซับซ้อนน้อยกว่า นี่หมายความว่ามันซับซ้อนน้อยกว่าใช่ไหม? อาจไม่ใช่ แต่เครื่องมือไม่สามารถมองเห็นสิ่งนี้ได้ เนื่องจากไม่ได้สร้าง AST ของโค้ดเนื่องจากจะสแกนผ่านโค้ดเท่านั้น
โดยทั่วไปแล้วแม้ว่าความซับซ้อนจะมีไว้เพื่อช่วยประมาณระหว่างโปรเจ็กต์ที่เขียนด้วยภาษาเดียวกัน หรือสำหรับการค้นหาไฟล์ที่ซับซ้อนที่สุดในโปรเจ็กต์ scc --by-file -s complexity ซึ่งจะมีประโยชน์เมื่อคุณกำลังประมาณว่าบางสิ่งยากแค่ไหน บำรุงรักษาหรือเมื่อค้นหาไฟล์เหล่านั้นที่ควรได้รับการปรับโครงสร้างใหม่
ส่วนวิธีการทำงานนั้น
มันเป็นคำจำกัดความของฉันเอง แต่พยายามที่จะประมาณความซับซ้อนของไซโคลมาติก https://en.wikipedia.org/wiki/Cyclomatic_complexity แม้ว่าจะทำได้ในระดับไฟล์เท่านั้น
เหตุผลที่เป็นการประมาณก็คือ มันถูกคำนวณเกือบจะฟรีจากมุมมองของ CPU (เนื่องจากเป็นการค้นหาที่ราคาถูกเมื่อทำการนับ) ในขณะที่การนับความซับซ้อนแบบไซโคลเมติกจริงจะต้องแยกวิเคราะห์โค้ด มันให้การคาดเดาที่สมเหตุสมผลในทางปฏิบัติ แม้ว่าจะล้มเหลวในการระบุวิธีการเรียกซ้ำก็ตาม เป้าหมายไม่ใช่เพื่อให้มันแม่นยำ
กล่าวโดยย่อคือเมื่อ scc ดูสิ่งที่ระบุว่าเป็นโค้ด ถ้ามันสังเกตเห็นว่าเงื่อนไขของสาขามักจะเป็นอย่างไร มันจะเพิ่มตัวนับ
เงื่อนไขที่ค้นหาจะถูกรวบรวมไว้ในโค้ด และคุณสามารถรับแนวคิดได้โดยดูที่ JSON ภายในที่เก็บ ดูhttps://github.com/boyter/scc/blob/master/ languages.json#L3869เพื่อดูตัวอย่างสิ่งที่ต้องการสำหรับไฟล์ที่เป็น Java
การเพิ่มขึ้นจะเกิดขึ้นสำหรับแต่ละเงื่อนไขที่ตรงกันและสร้างตัวเลขที่คุณเห็น
บรรทัดรหัสเฉพาะ (ULOC)
ULOC ย่อมาจาก Unique Lines of Code และแสดงถึงบรรทัดที่ไม่ซ้ำกันในภาษา ไฟล์ และตัวโครงการเอง แนวคิดนี้นำมาจาก https://cmcenroe.me/2018/12/14/uloc.html ซึ่งนำเสนอการคำนวณโดยใช้เครื่องมือ Unix มาตรฐาน sort -u *.h *.c | wc -l ตัวชี้วัดนี้มีไว้เพื่อช่วยในการประมาณค่าความซับซ้อนภายในโครงการ อ้างอิงแหล่งที่มา
ในความคิดของฉัน จำนวนที่สร้างขึ้นควรเป็นการประมาณความซับซ้อนของโครงการได้ดีกว่า เมื่อเปรียบเทียบกับ SLOC ไม่เพียงแต่จะมีการลดราคาบรรทัดว่างเท่านั้น แต่ยังรวมถึงวงเล็บปีกกาแบบปิดและโค้ดที่ซ้ำกันอื่นๆ เช่น การรวมทั่วไปด้วย ในทางกลับกัน ULOC จะนับความคิดเห็นซึ่งต้องการการบำรุงรักษามากพอๆ กับโค้ดที่อยู่รอบๆ ขณะเดียวกันก็หลีกเลี่ยงการขยายผลลัพธ์ด้วยส่วนหัวลิขสิทธิ์ที่ปรากฏในทุกไฟล์ เป็นต้น
คุณสามารถรับ ULOC ได้โดยระบุอาร์กิวเมนต์ -u หรือ --uloc ให้กับ scc
โดยมีตัวชี้วัด DRYness % ที่สอดคล้องกัน ซึ่งเป็นเปอร์เซ็นต์ของ ULOC ถึง CLOC หรือ DRYness = ULOC / SLOC ยิ่งตัวเลขสูงก็ยิ่งแห้งมากขึ้น (อย่าทำซ้ำตัวเอง) ก็สามารถพิจารณาโครงการได้ โดยทั่วไปค่าที่สูงกว่าตรงนี้จะดีกว่า เนื่องจากเป็นการบ่งชี้โค้ดที่ซ้ำกันน้อยกว่า ตัวชี้วัด DRYness นำมาจากความคิดเห็นโดย minimax https://lobste.rs/s/has9r7/uloc_unique_lines_code
หากต้องการรับตัวชี้วัด DRYness คุณสามารถใช้อาร์กิวเมนต์ -a หรือ --dryness เพื่อ scc ซึ่งจะตั้งค่าโดยปริยาย --uloc
โปรดทราบว่ามีการปรับประสิทธิภาพเมื่อคำนวณเมตริก ULOC ซึ่งสามารถเพิ่มรันไทม์ได้เป็นสองเท่า
การรันการคำนวณ uloc และ DRYness กับโค้ด C โคลนของ 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"
บ้านแฝด – โครงการซอฟต์แวร์กล่าวกันว่าเป็นโครงการบ้านแฝด หากลักษณะสำคัญ เช่น ขนาดทีม ประสบการณ์ ความรู้เกี่ยวกับสภาพแวดล้อมการเขียนโปรแกรมต่างๆ อยู่ระหว่างลักษณะทั่วไปและแบบฝังตัว โครงการที่จัดเป็นโครงการแฝดมีความคุ้นเคยน้อยกว่าและยากต่อการพัฒนาเมื่อเปรียบเทียบกับโครงการออร์แกนิก และต้องการประสบการณ์มากกว่า รวมถึงคำแนะนำและความคิดสร้างสรรค์ที่ดีกว่า เช่น คอมไพเลอร์หรือระบบสมองกลฝังตัวอื่นสามารถพิจารณาได้ว่าเป็นประเภทกึ่งแยกเดี่ยว
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
Embedded – โครงการซอฟต์แวร์ที่ต้องการความซับซ้อน ความคิดสร้างสรรค์ และประสบการณ์ในระดับสูงสุดจัดอยู่ในหมวดหมู่นี้ ซอฟต์แวร์ดังกล่าวต้องการขนาดทีมที่ใหญ่กว่าอีกสองรุ่น และนักพัฒนาจำเป็นต้องมีประสบการณ์และความคิดสร้างสรรค์เพียงพอที่จะพัฒนาโมเดลที่ซับซ้อนดังกล่าว
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 และเลือกที่จะลบไฟล์ที่ระบุว่าเป็นไฟล์ที่ถูกย่อขนาดหรือสร้างจากเอาต์พุตได้
คุณสามารถทำได้โดยเปิดใช้งานแฟล็ก -z เช่นนั้น scc -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) หลังชื่อภาษา
คุณสามารถควบคุมขนาดไบต์ของบรรทัดโดยเฉลี่ยได้โดยใช้ --min-gen-line-length เช่น scc -z --min-gen-line-length 1 โปรดทราบว่าคุณต้องมี -z เนื่องจากการแก้ไขค่านี้ไม่ได้หมายความถึงการตรวจจับที่ย่อเล็กสุด
คุณสามารถยกเว้นไฟล์ย่อขนาดจากการนับได้ทั้งหมดโดยใช้แฟล็ก --no-min-gen ไฟล์ที่ตรงกับการตรวจสอบแบบย่อส่วนจะถูกแยกออกจากเอาต์พุต
การแมปใหม่
ไฟล์บางไฟล์อาจไม่มีนามสกุล พวกเขาจะถูกตรวจสอบว่าเป็น #! ไฟล์. หากเป็นเช่นนั้น ภาษาจะถูกแมปใหม่เป็นภาษาที่ถูกต้อง มิฉะนั้นจะไม่ดำเนินการ
อย่างไรก็ตาม คุณอาจมีสถานการณ์ที่คุณต้องการทำการแมปไฟล์ดังกล่าวใหม่โดยยึดตามสตริงที่อยู่ภายใน หากต้องการทำเช่นนั้น คุณสามารถใช้ --remap-unknown
scc --remap-unknown "-*- C++ -*-":"C Header"
ข้างต้นจะตรวจสอบไฟล์ใดๆ ที่ไม่มีนามสกุลที่มองหาสตริง -*- C++ -*- และหากพบว่าทำการแมปไฟล์ใหม่ที่จะนับโดยใช้กฎ C Header คุณสามารถมีกฎการแมปได้หลายกฎหากจำเป็น
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
โปรดทราบว่าคุณสามารถเขียนเอาต์พุต scc ลงดิสก์ได้โดยใช้ตัวเลือก -o, --output ซึ่งจะทำให้คุณสามารถระบุไฟล์ที่จะเขียนเอาต์พุตของคุณได้ ตัวอย่างเช่น scc -f html -o output.html จะรัน scc กับไดเร็กทอรีปัจจุบัน และเอาต์พุตผลลัพธ์เป็น html ไปยังไฟล์ output.html
คุณยังสามารถเขียนไปยังไฟล์เอาต์พุตหลายไฟล์หรือหลายประเภทไปยัง stdout ได้หากคุณต้องการใช้ตัวเลือก --format-multi สิ่งนี้มีประโยชน์มากที่สุดเมื่อทำงานในระบบ CI/CD ที่คุณต้องการให้รายงาน HTML เป็นอาร์ติแฟกต์ในขณะที่แสดงจำนวนใน stdout ด้วย
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
ข้อมูลข้างต้นจะทำงานกับไดเร็กทอรีปัจจุบัน โดยส่งออกไปยังเอาต์พุตมาตรฐานซึ่งเป็นเอาต์พุตเริ่มต้น เช่นเดียวกับการเขียนไปยัง output.html และ output.csv ด้วยรูปแบบที่เหมาะสม
แบบตาราง
นี่เป็นรูปแบบเอาต์พุตเริ่มต้นเมื่อรัน scc
กว้าง
Wide จะให้ข้อมูลเพิ่มเติมบางอย่างซึ่งเป็นเมตริกความซับซ้อน/เส้น สิ่งนี้มีประโยชน์เมื่อพยายามระบุไฟล์ที่ซับซ้อนที่สุดภายในโปรเจ็กต์ตามการประมาณความซับซ้อน
เจสัน
JSON สร้างเอาต์พุต JSON ส่วนใหญ่ออกแบบมาเพื่อให้ scc สามารถฟีดเข้าสู่โปรแกรมอื่นได้
โปรดทราบว่ารูปแบบนี้จะให้ขนาดไบต์ของทุกไฟล์ที่อ่าน scc เพื่อให้คุณสามารถแจกแจงจำนวนไบต์ที่ประมวลผลได้
ซีเอสวี
CSV เป็นตัวเลือกที่ดีสำหรับการนำเข้าสู่สเปรดชีตเพื่อการวิเคราะห์
โปรดทราบว่ารูปแบบนี้จะให้ขนาดไบต์ของทุกไฟล์ที่อ่าน scc เพื่อให้คุณสามารถแจกแจงจำนวนไบต์ที่ประมวลผลได้ โปรดทราบว่า CSV เคารพ --by-file และด้วยเหตุนี้จึงจะส่งกลับข้อมูลสรุปตามค่าเริ่มต้น
CSV-สตรีม
csv-stream เป็นตัวเลือกที่มีประโยชน์สำหรับการประมวลผลที่เก็บข้อมูลขนาดใหญ่มากซึ่งคุณมีแนวโน้มที่จะประสบปัญหาหน่วยความจำ รูปแบบเอาต์พุตจะเหมือนกับ CSV 100%
โปรดทราบว่าคุณไม่ควรใช้ตัวเลือกนี้กับตัวเลือก format-multi เนื่องจากมันจะพิมพ์ไปยังเอาต์พุตมาตรฐานเสมอ และเนื่องจากวิธีการทำงานจะทำให้การประหยัดหน่วยความจำที่ได้รับตามปกติลดลง เงินออมที่ตัวเลือกนี้มอบให้ โปรดทราบว่าไม่มีการจัดเรียงที่ใช้กับตัวเลือกนี้
cloc-yaml
เป็นการแทนที่ cloc โดยใช้ตัวเลือกเอาต์พุต yaml ซึ่งมักใช้เพื่อส่งผ่านไปยังระบบบิลด์อื่นๆ และสามารถช่วยในการเปลี่ยน 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 ของคุณเองได้ ข้อแตกต่างระหว่างทั้งสองก็คือตัวเลือก html มีแท็ก html head และ body พร้อมสไตล์ที่เรียบง่าย
มาร์กอัปได้รับการออกแบบมาเพื่อให้สามารถปรับใช้สไตล์ที่คุณกำหนดเองได้ มีรายงานตัวอย่างอยู่ที่นี่เพื่อดู
โปรดทราบว่าตัวเลือก HTML เป็นไปตามตัวเลือกบรรทัดคำสั่ง ดังนั้นคุณสามารถใช้ scc --by-file -f html เพื่อสร้างรายงานที่มีทุกไฟล์ ไม่ใช่แค่สรุปเท่านั้น
โปรดทราบว่ารูปแบบนี้หากมีตัวเลือก --by-file จะทำให้คุณมีขนาดไบต์ของทุกไฟล์ที่อ่าน scc เพื่อให้คุณสามารถแจกแจงจำนวนไบต์ที่ประมวลผลได้
SQL และ SQL-Insert
รูปแบบเอาต์พุต SQL "ส่วนใหญ่" เข้ากันได้กับรูปแบบเอาต์พุต SQL ของ cloc https://github.com/AlDanial/cloc#sql-
แม้ว่าแบบสอบถามทั้งหมดในเอกสารประกอบ cloc ควรทำงานตามที่คาดไว้ คุณจะไม่สามารถผนวกเอาต์พุตจาก scc และ cloc ลงในฐานข้อมูลเดียวกันได้ เนื่องจากรูปแบบตารางจะแตกต่างออกไปเล็กน้อยเมื่อคำนึงถึง scc รวมถึงจำนวนและไบต์ที่ซับซ้อน
ความแตกต่างระหว่าง sql และ sql-insert คือ sql จะรวมการสร้างตารางในขณะที่อย่างหลังจะมีเพียงคำสั่ง insert เท่านั้น
การใช้งานเหมือนกับคำสั่ง scc อื่นๆ 100% แต่เอาต์พุต sql จะมีรายละเอียดต่อไฟล์เสมอ คุณสามารถคำนวณผลรวมได้ด้วยตัวเองโดยใช้ SQL อย่างไรก็ตาม การคำนวณ COCOMO จะปรากฏเทียบกับ
