Sloc Cloc und Code (scc)
Ein ähnliches Tool wie cloc, sloccount und tokei. Zum Zählen der Codezeilen, Leerzeilen, Kommentarzeilen und physischen Quellcodezeilen in vielen Programmiersprachen.
Ziel ist es, der schnellstmögliche Codezähler zu sein, aber auch COCOMO-Berechnungen wie Sloccount durchzuführen, die Codekomplexität ähnlich wie zyklomatische Komplexitätsrechner zu schätzen und eindeutige Codezeilen oder DRYness-Metriken zu erstellen. Kurz gesagt, ein Werkzeug, um sie alle zu beherrschen.
Außerdem hat es einen sehr kurzen Namen, der sich leicht eingeben lässt scc .
Wenn Sie Sloc Cloc und Code nicht mögen, können Sie gerne den Namen Succinct Code Counter verwenden.
Lizenziert unter MIT-Lizenz.
Inhaltsverzeichnis
Unterstützung
scc kommerziell nutzen? Wenn Sie vorrangigen Support für scc wünschen, können Sie ein Jahr im Wert von https://boyter.gumroad.com/l/kgenuv erwerben, das Sie zum vorrangigen direkten E-Mail-Support vom Entwickler berechtigt.
Installieren
Gehen Sie zu Installieren
Sie können scc mithilfe der Standard-Go-Toolchain installieren.
So installieren Sie die neueste stabile Version von scc:
go install github.com/boyter/scc/v3@latest
So installieren Sie eine Entwicklungsversion:
go install github.com/boyter/scc/v3@master
Beachten Sie, dass scc eine Go-Version >= 1.22 benötigt.
Schnapp
Dank Ricardo gibt es eine Schnellinstallation.
$ sudo snap install scc
Hinweis: Von Snap installierte Anwendungen können nicht außerhalb von /home https://askubuntu.com/questions/930437/permission-denied-error-when-running-apps-installed-as-snap-packages-ubuntu-17 ausgeführt werden, sodass möglicherweise Probleme auftreten wenn Sie Snap verwenden und versuchen, außerhalb dieses Verzeichnisses auszuführen.
Homebrew
Oder wenn Sie Homebrew installiert haben
$ brew install scc
MacPorts
Unter macOS können Sie auch über MacPorts installieren
$ sudo port install scc
Scoop
Oder wenn Sie Scoop unter Windows verwenden
$ scoop install scc
Schokoladend
Oder wenn Sie Chocolatey unter Windows verwenden
$ choco install scc
WinGet
Oder wenn Sie WinGet unter Windows verwenden
winget install --id benboyter.scc --source winget
FreeBSD
Unter FreeBSD ist scc als Paket verfügbar
$ pkg install scc
Wenn Sie lieber aus dem Quellcode erstellen möchten, können Sie auch den Ports-Baum verwenden
$ cd /usr/ports/devel/scc && make install clean
In Docker ausführen
Gehen Sie zu dem Verzeichnis, aus dem Sie scc ausführen möchten.
Führen Sie den folgenden Befehl aus, um die neueste Version von scc in Ihrem aktuellen Arbeitsverzeichnis auszuführen:
docker run --rm -it -v "$PWD:/pwd" ghcr.io/lhoupert/scc:master scc /pwd
Handbuch
Binärdateien für Windows, GNU/Linux und macOS für i386- und x86_64-Maschinen sind auf der Release-Seite verfügbar.
GitLab
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
Andere
Wenn Sie dabei helfen möchten, scc in apt/chocolatey/etc einzufügen, reichen Sie bitte eine PR ein oder äußern Sie zumindest ein Problem mit Anweisungen.
Hintergrund
Lesen Sie alles darüber, wie es dazu kam, zusammen mit Leistungsbenchmarks,
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/
Einige Rezensionen von 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
Ein Vortrag, der auf der ersten GopherCon AU über scc gehalten wurde (drücken Sie S, um die Vortragsnotizen anzuzeigen)
Informationen zur Leistung finden Sie im Abschnitt „Leistung“.
Andere ähnliche Projekte,
SLOCCount ist der ursprüngliche Sloc-Zähler
cloc, inspiriert von SLOCCount; zur Portabilität in Perl implementiert
Gocloc, ein von Tokei inspirierter Sloc-Zähler in Go
Loc Rust-Implementierung ähnlich wie Tokei, aber oft schneller
Loccount Go-Implementierung, geschrieben und gepflegt von ESR
mehrsprachiger ATS-Sloc-Zähler
Tokei schnell, genau und in Rost geschrieben
Sloc Coffeescript-Codezähler
stto neuer Go-Codezähler mit Fokus auf Leistung
Interessante Lektüre über andere Code-Zählprojekte tokei, loc, polyglot und 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
Weitere Informationen zur Verarbeitung von Dateien auf der Festplatte
Verwendung von scc zur Verarbeitung von 40 TB Dateien von GitHub/Bitbucket/GitLab
Tonhöhe
Warum scc verwenden?
Es ist sehr schnell und wird umso schneller, je mehr CPU man darauf verwendet
Genau
Funktioniert sehr gut auf mehreren Plattformen ohne Verlangsamung (Windows, Linux, macOS)
Große Sprachunterstützung
Kann doppelte Dateien ignorieren
Verfügt über Komplexitätsschätzungen
Sie müssen den Unterschied zwischen Coq und Verilog im selben Verzeichnis erkennen
Cloc-YAML-Ausgabeunterstützung, sodass für einige Benutzer möglicherweise kein Ersatz mehr vorhanden ist
Kann minimierte Dateien identifizieren oder ignorieren
Kann viele # identifizieren! Dateien ERWEITERT! #115
Kann große Dateien zeilen- oder byteweise ignorieren
Kann den ULOC oder einzelne Codezeilen nach Datei, Sprache oder Projekt berechnen
Unterstützt mehrere Ausgabeformate für Integration, CSV, SQL, JSON, HTML und mehr
Warum nicht scc verwenden?
Unterschiede
Es gibt einige wichtige Unterschiede zwischen scc und anderen verfügbaren Tools. Hier sind einige wichtige Punkte, die Sie berücksichtigen sollten.
Leerzeilen innerhalb von Kommentaren werden als Kommentare gezählt. Obwohl die Zeile technisch gesehen leer ist, wurde beschlossen, dass in einem Kommentar alles, was darin enthalten ist, als Kommentar betrachtet werden sollte, bis dieser Kommentar beendet wird. Daher Folgendes:
/* blank lines follow
*/
Würde als 4 Kommentarzeilen gezählt. Dies macht sich bemerkbar, wenn man die Ausgabe von scc mit anderen Tools in großen Repositorys vergleicht.
scc ist in der Lage, wörtliche Zeichenfolgen korrekt zu zählen. Zum Beispiel in C# das Folgende:
private const string BasePath = @"a:";
// The below is returned to the user as a version
private const string Version = "1.0.0";
Aufgrund des vorangestellten @ endet diese Zeichenfolge am Ende „, indem das Escape-Zeichen ignoriert wird, und sollte daher als 2 Codezeilen und 1 Kommentar gezählt werden. Einige Tools können damit nicht umgehen und zählen stattdessen bis „1.0.0“. als Zeichenfolge, die dazu führen kann, dass der mittlere Kommentar als Code und nicht als Kommentar gezählt wird.
scc teilt Ihnen auch die Anzahl der verarbeiteten Bytes mit (für die meisten Ausgabeformate), sodass Sie die Kosten für die Ausführung einiger statischer Analysetools abschätzen können.
Verwendung
Die Verwendung von scc über die Befehlszeile ist so einfach wie möglich gestaltet. Ausführliche Informationen finden Sie in scc --help oder scc -h . Beachten Sie, dass das Folgende den Status des Masters und nicht einer Version widerspiegelt, da die unten aufgeführten Funktionen in Ihrer Installation möglicherweise fehlen.
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)
Die Ausgabe für das Redis-Projekt sollte in etwa wie folgt aussehen
$ 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)
───────────────────────────────────────────────────────────────────────────────
Beachten Sie, dass Sie das Verzeichnis, in dem Sie ausführen möchten, nicht angeben müssen. Beim Ausführen von scc wird davon ausgegangen, dass Sie das aktuelle Verzeichnis ausführen möchten.
Sie können auch mehrere Dateien oder Verzeichnisse scc directory1 directory2 file1 file2 ausführen und die Ergebnisse in der Ausgabe aggregieren.
Da scc in die Standardausgabe schreibt, gibt es viele Möglichkeiten, die Ergebnisse einfach zu teilen. Wenn Sie beispielsweise netcat und einen von vielen Pastebins verwenden, erhalten Sie eine öffentliche URL:
$ scc | nc paste.c-net.org 9999
https://paste.c-net.org/Example
Dateien ignorieren
scc unterstützt hauptsächlich .ignore-Dateien in Verzeichnissen, die gescannt werden. Dies ähnelt der Funktionsweise von Ripgrep, Ag und Tokei. .ignore-Dateien sind zu 100 % identisch mit .gitignore-Dateien mit derselben Syntax, und daher ignoriert scc die darin aufgeführten Dateien und Verzeichnisse. Sie können .ignore-Dateien hinzufügen, um Dinge wie in Dateien eingecheckte Anbieterabhängigkeiten usw. zu ignorieren. Die Idee besteht darin, dass Sie eine Datei oder einen Ordner zu Git hinzufügen und diese bei der Zählung ignorieren können.
Es unterstützt auch seine eigene Ignorierdatei .sccignore wenn Sie möchten, dass scc Dinge ignoriert, während Ripgrep, Ag, Tokei und andere sie unterstützen.
Interessante Anwendungsfälle
Wird im Intel Nemu Hypervisor verwendet, um Codeänderungen zwischen Revisionen zu verfolgen https://github.com/intel/nemu/blob/topic/virt-x86/tools/cloc-change.sh#L9 Scheint auch in beiden http:/ verwendet zu werden. /codescoop.com/ https://pinpoint.com/ https://github.com/chaoss/grimoirelab-graal
Es wird auch zum Zählen von Codes und zum Erraten von Sprachtypen in https://searchcode.com/ verwendet, was es zu einem der am häufigsten ausgeführten Codezähler der Welt macht.
Sie können scc auch in Ihre Gitlab-Pipeline einbinden: https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-scc
Wird auch von CodeQL #317 und Scaleway verwendet https://twitter.com/Scaleway/status/1488087029476995074?s=20&t=N2-z6O-ISDdDzULg4o4uVQ
Merkmale
scc verwendet eine kleine Zustandsmaschine, um zu bestimmen, in welchem Zustand sich der Code befindet, wenn er eine neue Zeile n erreicht. Als solches ist es sich bewusst und kann zählen
Dadurch kann genau bestimmt werden, ob sich ein Kommentar in einer Zeichenfolge befindet oder tatsächlich ein Kommentar ist.
Es wird auch versucht, die Komplexität des Codes zu ermitteln. Dies erfolgt durch die Prüfung auf Verzweigungsoperationen im Code. Zum Beispiel jedes der folgenden for if switch while else || && != == würde bei Auftreten in Java die Komplexität dieser Datei um eins erhöhen.
Komplexitätsschätzungen
Nehmen wir uns eine Minute Zeit, um die Komplexitätsschätzung selbst zu besprechen.
Die Komplexitätsschätzung ist eigentlich nur eine Zahl, die nur mit Dateien in derselben Sprache vergleichbar ist. Es sollte nicht dazu verwendet werden, Sprachen direkt zu vergleichen, ohne sie zu gewichten. Der Grund dafür ist, dass die Berechnung durch die Suche nach Verzweigungs- und Schleifenanweisungen im Code und das Erhöhen eines Zählers für diese Datei erfolgt.
Da einige Sprachen keine Schleifen haben und stattdessen Rekursion verwenden, können sie eine geringere Komplexitätsanzahl aufweisen. Bedeutet das, dass sie weniger komplex sind? Wahrscheinlich nicht, aber das Tool kann dies nicht erkennen, da es keinen AST des Codes erstellt, sondern ihn nur durchsucht.
Im Allgemeinen dient die Komplexität jedoch dazu, die Schätzung zwischen Projekten zu erleichtern, die in derselben Sprache geschrieben sind, oder um die komplexeste Datei in einem Projekt zu finden. scc --by-file -s complexity kann nützlich sein, wenn Sie abschätzen möchten, wie schwierig etwas ist pflegen, oder wenn Sie nach Dateien suchen, die wahrscheinlich umgestaltet werden sollten.
Was die Funktionsweise betrifft.
Es ist meine eigene Definition, versucht aber, eine Annäherung an die zyklomatische Komplexität https://en.wikipedia.org/wiki/Cyclomatic_complexity zu sein, obwohl dies nur auf Dateiebene erfolgt.
Der Grund dafür, dass es sich um eine Näherung handelt, liegt darin, dass die Berechnung aus CPU-Sicht nahezu kostenlos erfolgt (da es sich um eine kostengünstige Suche beim Zählen handelt), wohingegen eine echte zyklomatische Komplexitätszählung den Code analysieren müsste. In der Praxis liefert es jedoch eine vernünftige Vermutung, auch wenn rekursive Methoden nicht identifiziert werden können. Das Ziel war nie, dass es genau ist.
Kurz gesagt, wenn scc das durchsieht, was es als Code identifiziert hat, erhöht es einen Zähler, wenn es erkennt, was normalerweise Verzweigungsbedingungen sind.
Die gesuchten Bedingungen werden in den Code kompiliert und Sie können sich ein Bild davon machen, indem Sie sich den JSON-Code im Repository ansehen. Unter https://github.com/boyter/scc/blob/master/linguals.json#L3869 finden Sie ein Beispiel dafür, was nach einer Java-Datei gesucht wird.
Die Erhöhung erfolgt für jede der übereinstimmenden Bedingungen und ergibt die angezeigte Zahl.
Einzigartige Codezeilen (ULOC)
ULOC steht für Unique Lines of Code und repräsentiert die eindeutigen Zeilen über Sprachen, Dateien und das Projekt selbst hinweg. Diese Idee wurde von https://cmcenroe.me/2018/12/14/uloc.html übernommen, wo die Berechnung mit Standard-Unix-Tools sort -u *.h *.c | wc -l dargestellt wird sort -u *.h *.c | wc -l . Diese Metrik soll bei der Einschätzung der Komplexität innerhalb des Projekts helfen. Zitieren der Quelle
Meiner Meinung nach sollte die daraus resultierende Zahl eine bessere Einschätzung der Komplexität eines Projekts sein. Im Vergleich zu SLOC werden nicht nur Leerzeilen, sondern auch Zeilen mit engen Klammern und anderer sich wiederholender Code, wie z. B. gemeinsame Includes, rabattiert. Andererseits zählt ULOC Kommentare, die genauso viel Pflege erfordern wie der Code um sie herum, und vermeidet dabei, das Ergebnis beispielsweise durch Lizenzheader aufzublähen, die in jeder Datei vorkommen.
Sie können den ULOC erhalten, indem Sie das Argument -u oder --uloc an scc übergeben.
Es gibt eine entsprechende Metrik DRYness % , die den Prozentsatz von ULOC zu CLOC oder DRYness = ULOC / SLOC darstellt. Je höher die Zahl, desto trockener (wiederholen Sie sich nicht) kann das Projekt in Betracht gezogen werden. Im Allgemeinen ist hier ein höherer Wert besser, da er auf weniger duplizierten Code hinweist. Die DRYness-Metrik wurde einem Kommentar von minimax https://lobste.rs/s/has9r7/uloc_unique_lines_code entnommen
Um die DRYness-Metrik zu erhalten, können Sie das Argument -a oder --dryness für scc verwenden, wodurch implizit --uloc festgelegt wird.
Beachten Sie, dass es bei der Berechnung der ULOC-Metriken zu Leistungseinbußen kommt, die die Laufzeit verdoppeln können.
Das Ausführen der uloc- und DRYness-Berechnungen mit C-Code eines Redis-Klons erzeugt die folgende Ausgabe.
$ 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)
───────────────────────────────────────────────────────────────────────────────
Weitere Informationen zur ULOC-Berechnung finden Sie unter https://boyter.org/posts/sloc-cloc-code-new-metic-uloc/
COCOMO
Die am Ende jeder Befehlszeilenausführung angezeigten COCOMO-Statistiken können nach Bedarf konfiguriert werden.
Estimated Cost to Develop (organic) $664,081
Estimated Schedule Effort (organic) 11.772217 months
Estimated People Required (organic) 5.011633
Um die COCOMO-Parameter zu ändern, können Sie entweder eines der Standard-COCOMO-Modelle verwenden.
scc --cocomo-project-type organic
scc --cocomo-project-type semi-detached
scc --cocomo-project-type embedded
Wenn Sie mit COCOMO vertraut sind, können Sie auch Ihre eigenen Parameter wie folgt angeben:
scc --cocomo-project-type "custom,1,1,1,1"
Nachfolgend finden Sie Einzelheiten zu den Modellauswahlmöglichkeiten und den verwendeten Parametern.
Organisch – Ein Softwareprojekt gilt als organisch, wenn die erforderliche Teamgröße ausreichend klein ist, das Problem gut verstanden und in der Vergangenheit gelöst wurde und auch die Teammitglieder über eine gewisse Erfahrung mit dem Problem verfügen.
scc --cocomo-project-type "organic,2.4,1.05,2.5,0.38"
Halbunabhängig – Ein Softwareprojekt gilt als halbunabhängig, wenn die wesentlichen Merkmale wie Teamgröße, Erfahrung und Kenntnisse der verschiedenen Programmierumgebungen zwischen denen eines organischen und eines eingebetteten Projekts liegen. Die als Doppelhaushälfte klassifizierten Projekte sind im Vergleich zu den organischen Projekten vergleichsweise weniger vertraut und schwieriger zu entwickeln und erfordern mehr Erfahrung sowie eine bessere Anleitung und Kreativität. Beispiel: Compiler oder verschiedene eingebettete Systeme können als Semi-Detached-Systeme betrachtet werden.
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
Eingebettet – Ein Softwareprojekt, das ein Höchstmaß an Komplexität, Kreativität und Erfahrung erfordert, fällt in diese Kategorie. Eine solche Software erfordert eine größere Teamgröße als die beiden anderen Modelle und außerdem müssen die Entwickler über ausreichend Erfahrung und Kreativität verfügen, um solch komplexe Modelle zu entwickeln.
scc --cocomo-project-type "embedded,3.6,1.20,2.5,0.32"
Erkennung großer Dateien
Sie können festlegen, dass scc große Dateien von der Ausgabe ausschließt.
Die Option hierfür ist --no-large , die standardmäßig Dateien mit mehr als 1.000.000 Byte oder 40.000 Zeilen ausschließt.
Sie können die Größe beider Werte mit --large-byte-count oder --large-line-count steuern.
Um beispielsweise Dateien mit mehr als 1.000 Zeilen und 50 KB auszuschließen, könnten Sie Folgendes verwenden:
scc --no-large --large-byte-count 50000 --large-line-count 1000
Erkennung minimierter/generierter Dateien
Sie können scc veranlassen, Dateien, die als minimiert identifiziert oder generiert wurden, aus der Ausgabe zu identifizieren und optional zu entfernen.
Sie können dies tun, indem Sie das Flag -z wie scc -z aktivieren, das jede Datei mit einer durchschnittlichen Zeilenbytegröße >= 255 (standardmäßig) als minimiert identifiziert.
Minimierte Dateien werden in der Ausgabe so angezeigt.
$ 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)
───────────────────────────────────────────────────────────────────────────────
Minimierte Dateien werden durch den Text (min) nach dem Sprachnamen gekennzeichnet.
Generierte Dateien werden mit dem Text (gen) nach dem Sprachnamen gekennzeichnet.
Sie können die durchschnittliche Zeilenbytegröße mit --min-gen-line-length wie scc -z --min-gen-line-length 1 steuern. Bitte beachten Sie, dass Sie -z benötigen, da das Ändern dieses Werts keine minimierte Erkennung bedeutet.
Mit dem Flag --no-min-gen können Sie minimierte Dateien vollständig von der Zählung ausschließen. Dateien, die der minimierten Prüfung entsprechen, werden von der Ausgabe ausgeschlossen.
Neuzuordnung
Einige Dateien haben möglicherweise keine Erweiterung. Es wird überprüft, ob es sich um ein # handelt! Datei. Wenn dies der Fall ist, wird die Sprache der richtigen Sprache zugeordnet. Andernfalls wird die Verarbeitung nicht durchgeführt.
Es kann jedoch vorkommen, dass Sie solche Dateien basierend auf einer darin enthaltenen Zeichenfolge neu zuordnen möchten. Dazu können Sie --remap-unknown verwenden
scc --remap-unknown "-*- C++ -*-":"C Header"
Das Obige untersucht jede Datei ohne Erweiterung auf die Zeichenfolge -*- C++ -*- und ordnet die zu zählende Datei, falls sie gefunden wird, mithilfe der C-Header-Regeln neu zu. Sie können bei Bedarf mehrere Neuzuordnungsregeln haben,
scc --remap-unknown "-*- C++ -*-":"C Header","other":"Java"
Es gibt auch den Parameter --remap-all , der alle Dateien neu zuordnet.
Beachten Sie, dass in allen Fällen, wenn die Neuzuordnungsregel nicht gilt, normales #! Es gelten die Regeln.
Ausgabeformate
Standardmäßig wird scc auf der Konsole ausgegeben. Bei Bedarf können Sie die Ausgabe jedoch auch in anderen Formaten erstellen.
Die verschiedenen Optionen sind tabular, wide, json, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetrics .
Beachten Sie, dass Sie scc Ausgabe mit der Option -o, --output auf die Festplatte schreiben können. Auf diese Weise können Sie eine Datei angeben, in die Ihre Ausgabe geschrieben werden soll. Beispielsweise führt scc -f html -o output.html scc für das aktuelle Verzeichnis aus und gibt die Ergebnisse im HTML-Format in die Datei „ output.html aus.
Sie können auch in mehrere Ausgabedateien oder mehrere Typen in stdout schreiben, wenn Sie die Option --format-multi verwenden möchten. Dies ist am nützlichsten, wenn Sie in CI/CD-Systemen arbeiten, in denen Sie HTML-Berichte als Artefakt wünschen und gleichzeitig die Zählungen in stdout anzeigen möchten.
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
Das Obige wird für das aktuelle Verzeichnis ausgeführt, gibt die Standardausgabe in die Standardausgabe aus und schreibt in die entsprechenden Formate in „output.html“ und „output.csv“.
Tabellarisch
Dies ist das Standardausgabeformat, wenn scc ausgeführt wird.
Breit
Wide erzeugt einige zusätzliche Informationen, nämlich die Komplexitäts-/Linienmetrik. Dies kann nützlich sein, wenn Sie versuchen, die komplexeste Datei innerhalb eines Projekts anhand der Komplexitätsschätzung zu identifizieren.
JSON
JSON erzeugt eine JSON-Ausgabe. Hauptsächlich dafür gedacht, scc in andere Programme einspeisen zu können.
Beachten Sie, dass Sie mit diesem Format die Bytegröße jeder scc gelesenen Datei erhalten, sodass Sie eine Aufschlüsselung der Anzahl der verarbeiteten Bytes erhalten.
CSV
CSV als Option eignet sich gut zum Importieren in eine Tabellenkalkulation zur Analyse.
Beachten Sie, dass Sie mit diesem Format die Bytegröße jeder scc gelesenen Datei erhalten, sodass Sie eine Aufschlüsselung der Anzahl der verarbeiteten Bytes erhalten. Beachten Sie außerdem, dass CSV --by-file berücksichtigt und daher standardmäßig eine Zusammenfassung zurückgibt.
CSV-Stream
csv-stream ist eine nützliche Option für die Verarbeitung sehr großer Repositorys, bei denen es wahrscheinlich zu Speicherproblemen kommt. Das Ausgabeformat ist zu 100 % dasselbe wie CSV.
Beachten Sie, dass Sie dies nicht mit der Option format-multi verwenden sollten, da diese immer auf der Standardausgabe druckt und aufgrund ihrer Funktionsweise die normalerweise erzielte Speicherersparnis zunichte macht. Einsparungen, die diese Option bietet. Beachten Sie, dass bei dieser Option keine Sortierung angewendet wird.
cloc-yaml
Ist ein Drop-in-Ersatz für cloc mithilfe seiner Yaml-Ausgabeoption. Dies wird häufig für die Übergabe an andere Build-Systeme verwendet und kann bei Bedarf beim Ersetzen von cloc hilfreich sein.
$ 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 und HTML-TABLE
Die HTML-Ausgabeoptionen erzeugen einen minimalen HTML-Bericht unter Verwendung einer Tabelle, die entweder eigenständiges html oder nur eine html-table ist, die in Ihre eigenen HTML-Seiten eingefügt werden kann. Der einzige Unterschied zwischen den beiden besteht darin, dass die html Option HTML-Head- und -Body-Tags mit minimalem Stil enthält.
Das Markup ist so konzipiert, dass Ihre eigenen benutzerdefinierten Stile angewendet werden können. Einen Beispielbericht finden Sie hier zur Ansicht.
Beachten Sie, dass die HTML-Optionen den Befehlszeilenoptionen folgen, sodass Sie scc --by-file -f html verwenden können, um einen Bericht mit jeder Datei und nicht nur mit der Zusammenfassung zu erstellen.
Beachten Sie, dass dieses Format, wenn es über die Option --by-file verfügt, Ihnen die Bytegröße jeder scc gelesenen Datei anzeigt, sodass Sie eine Aufschlüsselung der Anzahl der verarbeiteten Bytes erhalten.
SQL und SQL-Insert
Das SQL-Ausgabeformat ist „weitgehend“ kompatibel mit dem SQL-Ausgabeformat von cloc https://github.com/AlDanial/cloc#sql-
Während alle Abfragen in der Cloc-Dokumentation wie erwartet funktionieren sollten, können Sie die Ausgabe von scc und cloc nicht an dieselbe Datenbank anhängen. Dies liegt daran, dass sich das Tabellenformat geringfügig unterscheidet, um scc einschließlich Komplexitätsanzahl und Bytes zu berücksichtigen.
Der Unterschied zwischen sql und sql-insert besteht darin, dass sql die Tabellenerstellung umfasst, während letzteres nur über die Einfügebefehle verfügt.
Die Verwendung ist zu 100 % die gleiche wie bei jedem anderen scc Befehl, die SQL-Ausgabe enthält jedoch immer dateispezifische Details. Sie können Gesamtsummen mithilfe von SQL selbst berechnen, COCOMO-Berechnungen werden jedoch gegen die angezeigt
