scc
v3.4.0
Un outil similaire à cloc, sloccount et tokei. Pour compter les lignes de code, les lignes vides, les lignes de commentaires et les lignes physiques de code source dans de nombreux langages de programmation.
L'objectif est d'être le compteur de code le plus rapide possible, mais également d'effectuer des calculs COCOMO comme le sloccount, d'estimer la complexité du code similaire aux calculateurs de complexité cyclomatique et de produire des lignes de code uniques ou des métriques DRYness. Bref, un outil pour les gouverner tous.
Il a également un nom très court qui est facile à saisir scc .
Si vous n'aimez pas sloc cloc et code, n'hésitez pas à utiliser le nom Succinct Code Counter .
Sous licence MIT.
Soutien
Installer
Arrière-plan
Pas
Usage
Estimations de complexité
Lignes de code uniques (ULOC)
COCOMO
Formats de sortie
Performance
Développement
Ajouter/Modifier des langues
Problèmes
Insignes (bêta)
Prise en charge linguistique
Utiliser scc à des fins commerciales ? Si vous souhaitez une assistance prioritaire pour scc vous pouvez acheter une valeur d'un an https://boyter.gumroad.com/l/kgenuv qui vous donne droit à une assistance prioritaire par e-mail direct du développeur.
Vous pouvez installer scc en utilisant la chaîne d'outils go standard.
Pour installer la dernière version stable de scc :
go install github.com/boyter/scc/v3@latest
Pour installer une version de développement :
go install github.com/boyter/scc/v3@master
Notez que scc doit passer à la version >= 1.22.
Une installation instantanée existe grâce à Ricardo.
$ sudo snap install scc
Les applications installées NB Snap ne peuvent pas s'exécuter en dehors de /home https://askubuntu.com/questions/930437/permission-denied-error-when-running-apps-installed-as-snap-packages-ubuntu-17, vous pouvez donc rencontrer des problèmes si vous utilisez snap et tentez de l'exécuter en dehors de ce répertoire.
Ou si Homebrew est installé
$ brew install scc
Sur macOS, vous pouvez également installer via MacPorts
$ sudo port install scc
Ou si vous utilisez Scoop sous Windows
$ scoop install scc
Ou si vous utilisez Chocolatey sous Windows
$ choco install scc
Ou si vous utilisez WinGet sous Windows
winget install --id benboyter.scc --source winget
Sur FreeBSD, scc est disponible sous forme de package
$ pkg install scc
Ou, si vous préférez compiler à partir des sources, vous pouvez utiliser l'arborescence des ports
$ cd /usr/ports/devel/scc && make install clean
Accédez au répertoire à partir duquel vous souhaitez exécuter scc.
Exécutez la commande ci-dessous pour exécuter la dernière version de scc sur votre répertoire de travail actuel :
docker run --rm -it -v "$PWD:/pwd" ghcr.io/lhoupert/scc:master scc /pwd
Les binaires pour Windows, GNU/Linux et macOS pour les machines i386 et x86_64 sont disponibles sur la page des versions.
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
Si vous souhaitez aider à ajouter scc dans apt/chocolatey/etc... veuillez soumettre un PR ou au moins soulever un problème avec des instructions.
Découvrez comment cela a été créé, ainsi que les critères de performance,
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/
Quelques critiques de 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
Une conférence donnée lors de la première GopherCon AU sur scc (appuyez sur S pour voir les notes du conférencier)
https://boyter.org/static/gophercon-syd-presentation/
https://www.youtube.com/watch?v=jd-sjoy3GZo
Pour les performances, voir la section Performances
D'autres projets similaires,
SLOCCount le compteur de slocs d'origine
cloc, inspiré de SLOCCount ; implémenté en Perl pour la portabilité
gocloc un compteur de slocs en Go inspiré du tokei
implémentation de loc rust similaire à tokei mais souvent plus rapide
Implémentation de loccount Go écrite et maintenue par ESR
compteur de slocs ATS polyglotte
tokei rapide, précis et écrit en rouille
compteur de code sloc coffeescript
stto nouveau compteur de code Go axé sur les performances
Lecture intéressante sur d'autres projets de comptage de codes tokei, loc, polyglot et 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
Lectures complémentaires sur le traitement des fichiers sur les performances du disque
https://blog.burntsushi.net/ripgrep/
Utiliser scc pour traiter 40 To de fichiers depuis GitHub/Bitbucket/GitLab
https://boyter.org/posts/an-informal-survey-of-10-million-github-bitbucket-gitlab-projects/
Pourquoi utiliser scc ?
Il est très rapide et devient plus rapide à mesure que vous y consacrez plus de CPU
Précis
Fonctionne très bien sur plusieurs plateformes sans ralentissement (Windows, Linux, macOS)
Large prise en charge linguistique
Peut ignorer les fichiers en double
A des estimations de complexité
Vous devez faire la différence entre Coq et Verilog dans le même répertoire
prise en charge de la sortie cloc yaml, donc potentiellement un remplacement pour certains utilisateurs
Peut identifier ou ignorer les fichiers minifiés
Capable d'identifier plusieurs #! fichiers AVANCÉS ! #115
Peut ignorer les gros fichiers par lignes ou octets
Peut calculer l'ULOC ou des lignes de code uniques par fichier, langue ou projet
Prend en charge plusieurs formats de sortie pour l'intégration, CSV, SQL, JSON, HTML et plus encore
Pourquoi ne pas utiliser scc ?
Vous n'aimez pas Go pour une raison quelconque
Il ne peut pas compter correctement la source D avec différents commentaires multilignes imbriqués #27
Il existe des différences importantes entre scc et les autres outils disponibles. En voici quelques-uns importants à considérer.
Les lignes vides à l’intérieur des commentaires sont comptées comme des commentaires. Bien que la ligne soit techniquement vide, la décision a été prise qu'une fois dans un commentaire, tout ce qui s'y trouve devrait être considéré comme un commentaire jusqu'à ce que ce commentaire soit terminé. En tant que tel, ce qui suit,
/* blank lines follow */
Serait compté pour 4 lignes de commentaires. Ceci est visible lorsque l'on compare la sortie de scc à d'autres outils sur de grands référentiels.
scc est capable de compter correctement les chaînes textuelles. Par exemple en C# ce qui suit,
private const string BasePath = @"a:"; // The below is returned to the user as a version private const string Version = "1.0.0";
En raison du préfixe @, cette chaîne se termine par le " de fin en ignorant le caractère d'échappement et doit donc être comptée comme 2 lignes de code et 1 commentaire. Certains outils ne sont pas en mesure de gérer cela et comptent plutôt jusqu'au " 1.0.0 ". comme une chaîne qui peut faire en sorte que le commentaire du milieu soit compté comme du code plutôt que comme un commentaire.
scc vous indiquera également le nombre d'octets traités (pour la plupart des formats de sortie), vous permettant d'estimer le coût d'exécution de certains outils d'analyse statique.
L'utilisation de scc en ligne de commande est conçue pour être aussi simple que possible. Tous les détails peuvent être trouvés dans scc --help ou scc -h . Notez que ce qui suit reflète l'état du maître et non une version, car les fonctionnalités répertoriées ci-dessous peuvent être absentes de votre installation.
Sloc, Cloc and Code. Count lines of code in a directory with complexity estimation. Version 3.5.0 (beta) Ben Boyter <[email protected]> + 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,<auto-generated />]) -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)
La sortie devrait ressembler à ce qui suit pour le projet 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) ───────────────────────────────────────────────────────────────────────────────
Notez que vous n'avez pas besoin de spécifier le répertoire sur lequel vous souhaitez exécuter. L'exécution scc supposera que vous souhaitiez exécuter le répertoire actuel.
Vous pouvez également exécuter sur plusieurs fichiers ou répertoires scc directory1 directory2 file1 file2 avec les résultats agrégés dans la sortie.
Puisque scc écrit sur la sortie standard, il existe de nombreuses façons de partager facilement les résultats. Par exemple, utiliser netcat et l'un des nombreux pastebins donne une URL publique :
$ scc | nc paste.c-net.org 9999 https://paste.c-net.org/Example
scc prend principalement en charge les fichiers .ignore dans les répertoires qu'il analyse. Ceci est similaire au fonctionnement de ripgrep, ag et tokei. Les fichiers .ignore sont 100 % identiques aux fichiers .gitignore avec la même syntaxe, et en tant que tels, scc ignorera les fichiers et répertoires qui y sont répertoriés. Vous pouvez ajouter des fichiers .ignore pour ignorer des éléments tels que les dépendances du fournisseur enregistrées dans les fichiers, etc. L'idée est de vous permettre d'ajouter un fichier ou un dossier à git et de l'ignorer dans le décompte.
Il prend également en charge son propre fichier ignorer .sccignore si vous souhaitez que scc ignore les éléments tout en étant pris en charge par ripgrep, ag, tokei et d'autres.
Utilisé dans l'hyperviseur Intel Nemu pour suivre les modifications de code entre les révisions https://github.com/intel/nemu/blob/topic/virt-x86/tools/cloc-change.sh#L9 Semble également être utilisé dans les deux http:/ /codescoop.com/ https://pinpoint.com/ https://github.com/chaoss/grimoirelab-graal
Il est également utilisé pour compter le code et deviner les types de langage sur https://searchcode.com/, ce qui en fait l'un des compteurs de code les plus fréquemment exécutés au monde.
Vous pouvez également connecter scc à votre pipeline gitlab https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-scc
Également utilisé par CodeQL #317 et 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 utilise une petite machine à états afin de déterminer dans quel état se trouve le code lorsqu'il atteint une nouvelle ligne n . En tant que tel, il est conscient et capable de compter
Commentaires sur une seule ligne
Commentaires sur plusieurs lignes
Cordes
Chaînes multilignes
Lignes vides
De ce fait, il est capable de déterminer avec précision si un commentaire se trouve dans une chaîne ou s'il s'agit réellement d'un commentaire.
Il tente également de compter la complexité du code. Cela se fait en vérifiant les opérations de branchement dans le code. Par exemple, chacun des éléments suivants for if switch while else || && != == s'il est rencontré en Java, la complexité des fichiers augmenterait de un.
Prenons une minute pour discuter de l'estimation de la complexité elle-même.
L'estimation de la complexité n'est en réalité qu'un nombre comparable uniquement aux fichiers dans la même langue. Il ne doit pas être utilisé pour comparer directement les langues sans les pondérer. La raison en est que son calcul est effectué en recherchant des instructions de branchement et de boucle dans le code et en incrémentant un compteur pour ce fichier.
Étant donné que certains langages n'ont pas de boucles et utilisent à la place la récursivité, ils peuvent avoir un nombre de complexité inférieur. Cela signifie-t-il qu’ils sont moins complexes ? Probablement pas, mais l'outil ne peut pas le voir car il ne crée pas d'AST du code car il le parcourt uniquement.
En général, bien que la complexité soit là pour aider à estimer entre des projets écrits dans le même langage, ou pour trouver le fichier le plus complexe dans un projet, scc --by-file -s complexity peut être utile lorsque vous estimez la difficulté de quelque chose à maintenir, ou lors de la recherche de fichiers qui devraient probablement être refactorisés.
Quant à la façon dont cela fonctionne.
C'est ma propre définition, mais elle essaie d'être une approximation de la complexité cyclomatique https://en.wikipedia.org/wiki/Cyclomatic_complexity bien que cela soit fait uniquement au niveau du fichier.
La raison pour laquelle il s'agit d'une approximation est qu'elle est calculée presque gratuitement du point de vue du processeur (puisque c'est une recherche bon marché lors du comptage), alors qu'un véritable décompte de complexité cyclomatique nécessiterait d'analyser le code. Cela donne une estimation raisonnable dans la pratique, même s'il ne parvient pas à identifier les méthodes récursives. L’objectif n’a jamais été que ce soit exact.
En bref, lorsque scc examine ce qu'il a identifié comme code, s'il remarque ce qui est généralement des conditions de branche, il incrémente un compteur.
Les conditions qu'il recherche sont compilées dans le code et vous pouvez vous en faire une idée en consultant le JSON à l'intérieur du référentiel. Voir https://github.com/boyter/scc/blob/master/linguals.json#L3869 pour un exemple de ce qu'il recherche pour un fichier Java.
L'incrément se produit pour chacune des conditions correspondantes et produit le nombre que vous voyez.
ULOC signifie Unique Lines of Code et représente les lignes uniques à travers les langues, les fichiers et le projet lui-même. Cette idée est tirée de https://cmcenroe.me/2018/12/14/uloc.html où le calcul est présenté à l'aide des outils Unix standard sort -u *.h *.c | wc -l . Cette métrique est là pour aider à estimer la complexité du projet. Citant la source
À mon avis, le nombre que cela produit devrait être une meilleure estimation de la complexité d'un projet. Par rapport au SLOC, non seulement les lignes vides sont réduites, mais les lignes entre accolades et autres codes répétitifs tels que les inclusions communes le sont également. En revanche, ULOC compte les commentaires, qui nécessitent autant de maintenance que le code qui les entoure, tout en évitant de gonfler le résultat avec des en-têtes de licence qui apparaissent dans chaque fichier par exemple.
Vous pouvez obtenir l'ULOC en fournissant l'argument -u ou --uloc à scc .
Il a une métrique correspondante DRYness % qui est le pourcentage d'ULOC par rapport à CLOC ou DRYness = ULOC / SLOC . Plus le chiffre est élevé, plus le projet peut être considéré comme SEC (ne vous répétez pas). En général, une valeur plus élevée est meilleure car elle indique moins de code dupliqué. La métrique DRYness est tirée d'un commentaire de minimax https://lobste.rs/s/has9r7/uloc_unique_lines_code
Pour obtenir la métrique DRYness, vous pouvez utiliser l'argument -a ou --dryness pour scc , qui définira implicitement --uloc .
Notez qu'il existe une pénalité de performances lors du calcul des métriques ULOC qui peut doubler le temps d'exécution.
L'exécution des calculs uloc et DRYness sur le code C, un clone de redis produit le résultat suivant.
$ 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) ───────────────────────────────────────────────────────────────────────────────
Des informations complémentaires sur le calcul de l'ULOC peuvent être trouvées sur https://boyter.org/posts/sloc-cloc-code-new-metic-uloc/
Les statistiques COCOMO affichées au bas de toute exécution de ligne de commande peuvent être configurées selon les besoins.
Estimated Cost to Develop (organic) $664,081 Estimated Schedule Effort (organic) 11.772217 months Estimated People Required (organic) 5.011633
Pour modifier les paramètres COCOMO, vous pouvez soit utiliser l'un des modèles COCOMO par défaut.
scc --cocomo-project-type organic scc --cocomo-project-type semi-detached scc --cocomo-project-type embedded
Vous pouvez également fournir vos propres paramètres si vous êtes familier avec COCOMO comme suit :
scc --cocomo-project-type "custom,1,1,1,1"
Voir ci-dessous pour plus de détails sur la manière dont les modèles sont choisis et les paramètres qu'ils utilisent.
Organique – Un projet logiciel est dit de type organique si la taille de l’équipe requise est suffisamment petite, si le problème est bien compris et a été résolu dans le passé et si les membres de l’équipe ont également une expérience nominale du problème.
scc --cocomo-project-type "organic,2.4,1.05,2.5,0.38"
Semi-détaché – Un projet logiciel est dit de type semi-détaché si les caractéristiques vitales telles que la taille de l'équipe, l'expérience et la connaissance des différents environnements de programmation se situent entre celles de l'organique et de l'embarqué. Les projets classés comme semi-détachés sont comparativement moins familiers et difficiles à développer que les projets organiques et nécessitent plus d'expérience, un meilleur encadrement et une meilleure créativité. Ex : Les compilateurs ou différents systèmes embarqués peuvent être considérés comme de type semi-détaché.
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
Embarqué – Un projet logiciel nécessitant le plus haut niveau de complexité, de créativité et d’expérience entre dans cette catégorie. Un tel logiciel nécessite une équipe plus grande que les deux autres modèles et les développeurs doivent également être suffisamment expérimentés et créatifs pour développer des modèles aussi complexes.
scc --cocomo-project-type "embedded,3.6,1.20,2.5,0.32"
Vous pouvez demander à scc d'exclure les fichiers volumineux de la sortie.
L'option pour ce faire est --no-large qui exclura par défaut les fichiers de plus de 1 000 000 d'octets ou 40 000 lignes.
Vous pouvez contrôler la taille de l'une ou l'autre valeur en utilisant --large-byte-count ou --large-line-count .
Par exemple, pour exclure les fichiers de plus de 1 000 lignes et 50 Ko, vous pouvez utiliser ce qui suit :
scc --no-large --large-byte-count 50000 --large-line-count 1000
Vous pouvez demander à scc d'identifier et éventuellement de supprimer les fichiers identifiés comme étant minifiés ou générés à partir de la sortie.
Vous pouvez le faire en activant l'indicateur -z comme ceci scc -z qui identifiera tout fichier avec une taille moyenne en octets de ligne >= 255 (par défaut) comme étant minifié.
Les fichiers minifiés apparaissent ainsi dans la sortie.
$ 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) ───────────────────────────────────────────────────────────────────────────────
Les fichiers minifiés sont indiqués avec le texte (min) après le nom de la langue.
Les fichiers générés sont indiqués par le texte (gen) après le nom de la langue.
Vous pouvez contrôler la taille moyenne des octets de la ligne en utilisant --min-gen-line-length tel que scc -z --min-gen-line-length 1 . Veuillez noter que vous avez besoin -z car la modification de cette valeur n'implique pas une détection minifiée.
Vous pouvez exclure totalement les fichiers minifiés du décompte en utilisant l'indicateur --no-min-gen . Les fichiers qui correspondent à la vérification minifiée seront exclus de la sortie.
Certains fichiers peuvent ne pas avoir d'extension. Ils seront vérifiés pour voir s’il s’agit d’un # ! déposer. Si tel est le cas, la langue sera remappée dans la langue correcte. Sinon, le traitement ne sera pas effectué.
Cependant, vous pouvez vous trouver dans une situation où vous souhaitez remapper ces fichiers en fonction d'une chaîne qu'ils contiennent. Pour ce faire, vous pouvez utiliser --remap-unknown
scc --remap-unknown "-*- C++ -*-":"C Header"
Ce qui précède inspectera tout fichier sans extension à la recherche de la chaîne -*- C++ -*- et s'il est trouvé, remappera le fichier à compter en utilisant les règles d'en-tête C. Vous pouvez avoir plusieurs règles de remappage si nécessaire,
scc --remap-unknown "-*- C++ -*-":"C Header","other":"Java"
Il existe également le paramètre --remap-all qui remappera tous les fichiers.
Notez que dans tous les cas si la règle de remappage ne s'applique pas, le #! les règles s’appliqueront.
Par défaut, scc sera affiché sur la console. Cependant, vous pouvez produire une sortie dans d’autres formats si vous en avez besoin.
Les différentes options sont tabular, wide, json, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetrics .
Notez que vous pouvez écrire la sortie scc sur le disque en utilisant l'option -o, --output . Cela vous permet de spécifier un fichier dans lequel écrire votre sortie. Par exemple, scc -f html -o output.html exécutera scc sur le répertoire actuel et affichera les résultats en HTML dans le fichier output.html .
Vous pouvez également écrire dans plusieurs fichiers de sortie ou dans plusieurs types sur la sortie standard si vous le souhaitez en utilisant l'option --format-multi . Ceci est particulièrement utile lorsque vous travaillez dans des systèmes CI/CD où vous souhaitez des rapports HTML comme artefact tout en affichant également les décomptes dans la sortie standard.
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
Ce qui précède s'exécutera sur le répertoire actuel, produisant sur la sortie standard la sortie par défaut, ainsi que l'écriture dans output.html et output.csv avec les formats appropriés.
Il s'agit du format de sortie par défaut lorsque scc est exécuté.
Wide produit des informations supplémentaires qui sont la métrique de complexité/lignes. Cela peut être utile lorsque vous essayez d'identifier le fichier le plus complexe d'un projet en fonction de l'estimation de la complexité.
JSON produit une sortie JSON. Principalement conçu pour permettre à scc d'alimenter d'autres programmes.
Notez que ce format vous donnera la taille en octets de chaque lecture de fichier scc , vous permettant d'obtenir une répartition du nombre d'octets traités.
CSV en option est idéal pour l'importation dans une feuille de calcul à des fins d'analyse.
Notez que ce format vous donnera la taille en octets de chaque lecture de fichier scc , vous permettant d'obtenir une répartition du nombre d'octets traités. Notez également que CSV respecte --by-file et en tant que tel renverra un résumé par défaut.
csv-stream est une option utile pour traiter des référentiels très volumineux où vous risquez de rencontrer des problèmes de mémoire. Son format de sortie est 100 % identique à celui du CSV.
Notez que vous ne devez pas l'utiliser avec l'option format-multi car elle s'imprimera toujours sur la sortie standard et, en raison de son fonctionnement, annulera l'économie de mémoire qu'elle gagne normalement. économies que permet cette option. Notez qu'aucun tri n'est appliqué avec cette option.
Est un remplacement immédiat de cloc utilisant son option de sortie yaml. Ceci est assez souvent utilisé pour passer à d'autres systèmes de construction et peut aider à remplacer cloc si nécessaire.
$ 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
Les options de sortie HTML produisent un rapport HTML minimal utilisant un tableau qui est soit html autonome, soit un simple html-table qui peut être injecté dans vos propres pages HTML. La seule différence entre les deux est que l'option html inclut des balises html head et body avec un style minimal.
Le balisage est conçu pour permettre d’appliquer vos propres styles personnalisés. Un exemple de rapport est ici pour consulter.
Notez que les options HTML suivent les options de ligne de commande, vous pouvez donc utiliser scc --by-file -f html pour produire un rapport avec chaque fichier et pas seulement le résumé.
Notez que ce format, s'il possède l'option --by-file , vous donnera la taille en octets de chaque lecture de fichier scc vous permettant d'obtenir une répartition du nombre d'octets traités.
Le format de sortie SQL "principalement" compatible avec le format de sortie SQL de cloc https://github.com/AlDanial/cloc#sql-
Bien que toutes les requêtes sur la documentation cloc devraient fonctionner comme prévu, vous ne pourrez pas ajouter les sorties de scc et cloc dans la même base de données. En effet, le format du tableau est légèrement différent pour tenir compte du scc, y compris le nombre de complexités et les octets.
La différence entre sql et sql-insert est que sql inclura la création de table alors que ce dernier n'aura que les commandes d'insertion.
L'utilisation est 100 % la même que celle de toute autre commande scc , mais la sortie SQL contiendra toujours les détails par fichier. Vous pouvez calculer vous-même les totaux à l'aide de SQL, mais les calculs COCOMO apparaîtront par rapport aux
