Sloc Cloc y Código (scc)
Una herramienta similar a cloc, sloccount y tokei. Para contar líneas de código, líneas en blanco, líneas de comentarios y líneas físicas de código fuente en muchos lenguajes de programación.
El objetivo es ser el contador de código más rápido posible, pero también realizar cálculos COCOMO como sloccount, estimar la complejidad del código de manera similar a las calculadoras de complejidad ciclomática y producir líneas de código únicas o métricas de DRYness. En resumen, una herramienta para gobernarlos a todos.
También tiene un nombre muy corto que es fácil de escribir scc .
Si no le gustan el sloc cloc y el código, no dude en utilizar el nombre Succinct Code Counter .
Licenciado bajo licencia MIT.
Tabla de contenido
Apoyo
Instalar
Fondo
Paso
Uso
Estimaciones de complejidad
Líneas de código únicas (ULOC)
COCOMO
Formatos de salida
Actuación
Desarrollo
Agregar/modificar idiomas
Asuntos
Insignias (beta)
Soporte de idiomas
Apoyo
¿Utiliza scc comercialmente? Si desea soporte prioritario para scc puede comprar https://boyter.gumroad.com/l/kgenuv por un año, lo que le da derecho a soporte prioritario directo por correo electrónico del desarrollador.
Instalar
Ir a instalar
Puede instalar scc utilizando la cadena de herramientas go estándar.
Para instalar la última versión estable de scc:
go install github.com/boyter/scc/v3@latest
Para instalar una versión de desarrollo:
go install github.com/boyter/scc/v3@master
Tenga en cuenta que scc necesita ir a la versión >= 1.22.
Quebrar
Existe una instalación instantánea gracias a Ricardo.
$ sudo snap install scc
NB Las aplicaciones instaladas de Snap no se pueden ejecutar fuera de /home https://askubuntu.com/questions/930437/permission-denied-error-when-running-apps-installed-as-snap-packages-ubuntu-17, por lo que puede encontrar problemas si usa snap e intenta ejecutar fuera de este directorio.
cerveza casera
O si tienes Homebrew instalado
$ brew install scc
Puertos Mac
En macOS, también puedes instalar a través de MacPorts
$ sudo port install scc
Cuchara
O si estás usando Scoop en Windows
$ scoop install scc
chocolateado
O si estás usando Chocolatey en Windows
$ choco install scc
ganar
O si estás usando WinGet en Windows
winget install --id benboyter.scc --source winget
FreeBSD
En FreeBSD, scc está disponible como paquete
$ pkg install scc
O, si prefieres compilar desde el código fuente, puedes usar el árbol de puertos.
$ cd /usr/ports/devel/scc && make install clean
Ejecutar en Docker
Vaya al directorio desde el que desea ejecutar scc.
Ejecute el siguiente comando para ejecutar la última versión de scc en su directorio de trabajo actual:
docker run --rm -it -v "$PWD:/pwd" ghcr.io/lhoupert/scc:master scc /pwd
Manual
Los binarios para Windows, GNU/Linux y macOS para máquinas i386 y x86_64 están disponibles en la página de lanzamientos.
GitLab
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
Otro
Si desea ayudar a agregar scc a apt/chocolatey/etc... envíe un PR o al menos plantee un problema con instrucciones.
Fondo
Lea todo sobre cómo surgió junto con los puntos de referencia de rendimiento,
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/
Algunas reseñas de scc
https://nickmchardy.com/2018/10/counting-lines-of-code-in-koi-cms.html
https://www.feliciano.tech/blog/determinar-código-fuente-tamaño-y-complejidad-con-scc/
https://metaredux.com/posts/2019/12/13/counting-lines.html
Una charla dada en la primera GopherCon AU sobre scc (presione S para ver las notas del orador)
Para conocer el rendimiento, consulte la sección Rendimiento.
Otros proyectos similares,
SLOCCuenta el contador de sloc original
cloc, inspirado en SLOCCount; implementado en Perl para portabilidad
gocloc un contador de sloc en Go inspirado en tokei
Implementación de loc rust similar a tokei pero a menudo más rápida
Implementación de loccount Go escrita y mantenida por ESR
contador de sloc ATS políglota
tokei rápido, preciso y escrito en óxido
contador de código sloc coffeescript
stto nuevo contador de códigos Go centrado en el rendimiento
Lectura interesante sobre otros proyectos de conteo de códigos tokei, loc, políglota y 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
Lecturas adicionales sobre el rendimiento del procesamiento de archivos en el disco
Usando scc para procesar 40 TB de archivos desde GitHub/Bitbucket/GitLab
Paso
¿Por qué utilizar scc ?
Es muy rápido y se vuelve más rápido cuanto más CPU le pones.
Preciso
Funciona muy bien en múltiples plataformas sin ralentización (Windows, Linux, macOS)
Gran soporte de idiomas
Puede ignorar archivos duplicados
Tiene estimaciones de complejidad.
Debes diferenciar entre Coq y Verilog en el mismo directorio.
Compatibilidad con la salida cloc yaml, por lo que es posible que el reemplazo sea menor para algunos usuarios
Puede identificar o ignorar archivos minificados
Capaz de identificar muchos #! archivos ¡AVANZADO! #115
Puede ignorar archivos grandes por líneas o bytes
Puede calcular el ULOC o líneas únicas de código por archivo, idioma o proyecto.
Admite múltiples formatos de salida para integración, CSV, SQL, JSON, HTML y más
¿Por qué no utilizar scc ?
Diferencias
Existen algunas diferencias importantes entre scc y otras herramientas que existen. Aquí hay algunos importantes que debe considerar.
Las líneas en blanco dentro de los comentarios se cuentan como comentarios. Si bien la línea está técnicamente en blanco, se tomó la decisión de que una vez en un comentario, todo lo que hay allí debe considerarse un comentario hasta que finalice. Como tal lo siguiente,
/* blank lines follow
*/
Se contarían como 4 líneas de comentarios. Esto se nota al comparar el resultado de scc con otras herramientas en repositorios grandes.
scc es capaz de contar cadenas textuales correctamente. Por ejemplo, en C# lo siguiente,
private const string BasePath = @"a:";
// The below is returned to the user as a version
private const string Version = "1.0.0";
Debido al prefijo @, esta cadena termina al final " ignorando el carácter de escape y, como tal, debe contarse como 2 líneas de código y 1 comentario. Algunas herramientas no pueden manejar esto y en su lugar cuentan hasta "1.0.0". como una cadena que puede hacer que el comentario del medio se cuente como código en lugar de un comentario.
scc también le indicará la cantidad de bytes que ha procesado (para la mayoría de los formatos de salida), lo que le permitirá estimar el costo de ejecutar algunas herramientas de análisis estático.
Uso
El uso de la línea de comandos de scc está diseñado para ser lo más simple posible. Los detalles completos se pueden encontrar en scc --help o scc -h . Tenga en cuenta que lo siguiente refleja el estado de master, no una versión, ya que las funciones que se enumeran a continuación pueden faltar en su instalación.
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)
La salida debería verse similar a la siguiente para el proyecto 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)
───────────────────────────────────────────────────────────────────────────────
Tenga en cuenta que no es necesario especificar el directorio en el que desea ejecutar. Al ejecutar scc se asumirá que desea ejecutarlo en el directorio actual.
También puede ejecutarlo en varios archivos o directorios scc directory1 directory2 file1 file2 con los resultados agregados en la salida.
Dado que scc escribe en la salida estándar, existen muchas formas de compartir fácilmente los resultados. Por ejemplo, usar netcat y uno de los muchos pastebins proporciona una URL pública:
$ scc | nc paste.c-net.org 9999
https://paste.c-net.org/Example
Ignorar archivos
scc admite principalmente archivos .ignore dentro de los directorios que escanea. Esto es similar a cómo funcionan ripgrep, ag y tokei. Los archivos .ignore son 100% iguales que los archivos .gitignore con la misma sintaxis y, como tal, scc ignorará los archivos y directorios enumerados en ellos. Puede agregar archivos .ignore para ignorar cosas como la dependencia del proveedor registrada en archivos y demás. La idea es permitirle agregar un archivo o carpeta a git y haberlo ignorado en el recuento.
También admite su propio archivo de ignorar .sccignore si desea que scc ignore cosas mientras ripgrep, ag, tokei y otros los admiten.
Casos de uso interesantes
Se usa dentro del hipervisor Intel Nemu para rastrear cambios de código entre revisiones https://github.com/intel/nemu/blob/topic/virt-x86/tools/cloc-change.sh#L9 Parece que también se usa dentro de ambos http:/ /codescoop.com/ https://pinpoint.com/ https://github.com/chaoss/grimoirelab-graal
También se utiliza para contar códigos y adivinar tipos de idiomas en https://searchcode.com/, lo que lo convierte en uno de los contadores de códigos que se ejecutan con más frecuencia en el mundo.
También puede conectar scc a su canal de gitlab https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-scc
También utilizado por CodeQL #317 y Scaleway https://twitter.com/Scaleway/status/1488087029476995074?s=20&t=N2-z6O-ISDdDzULg4o4uVQ
Características
scc utiliza una pequeña máquina de estados para determinar en qué estado se encuentra el código cuando llega a una nueva línea n . Como tal, es consciente y capaz de contar.
Gracias a esto, puede determinar con precisión si un comentario está en una cadena o es realmente un comentario.
También intenta contar la complejidad del código. Esto se hace comprobando las operaciones de bifurcación en el código. Por ejemplo, cada uno de los siguientes for if switch while else || && != == si se encuentra en Java, incrementaría la complejidad de los archivos en uno.
Estimaciones de complejidad
Dediquemos un minuto a analizar la estimación de complejidad en sí.
La estimación de complejidad es en realidad sólo un número que sólo es comparable a archivos en el mismo idioma. No debe utilizarse para comparar idiomas directamente sin ponderarlos. La razón de esto es que se calcula buscando declaraciones de rama y bucle en el código e incrementando un contador para ese archivo.
Debido a que algunos lenguajes no tienen bucles y en su lugar usan recursividad, pueden tener un recuento de complejidad menor. ¿Significa esto que son menos complejos? Probablemente no, pero la herramienta no puede ver esto porque no crea un AST del código, ya que solo lo escanea.
En general, aunque la complejidad existe para ayudar a estimar entre proyectos escritos en el mismo idioma, o para encontrar el archivo más complejo en un proyecto, scc --by-file -s complexity puede ser útil cuando se estima qué tan difícil es algo. mantener, o cuando buscamos aquellos archivos que probablemente deberían ser refactorizados.
En cuanto a cómo funciona.
Es mi propia definición, pero intenta ser una aproximación de la complejidad ciclomática https://en.wikipedia.org/wiki/Cyclomatic_complexity aunque se realiza solo a nivel de archivo.
La razón por la que es una aproximación es que se calcula casi gratis desde el punto de vista de la CPU (ya que es una búsqueda barata al contar), mientras que un recuento de complejidad ciclomática real necesitaría analizar el código. Sin embargo, ofrece una suposición razonable en la práctica incluso si no logra identificar métodos recursivos. El objetivo nunca fue que fuera exacto.
En resumen, cuando scc revisa lo que ha identificado como código, si nota cuáles son generalmente condiciones de bifurcación, incrementará un contador.
Las condiciones que busca están compiladas en el código y puede hacerse una idea mirando el JSON dentro del repositorio. Consulte https://github.com/boyter/scc/blob/master/languages.json#L3869 para ver un ejemplo de lo que busca en un archivo Java.
El incremento ocurre para cada una de las condiciones coincidentes y produce el número que ve.
Líneas de código únicas (ULOC)
ULOC significa Unique Lines of Code y representa las líneas únicas en todos los idiomas, archivos y el proyecto en sí. Esta idea fue tomada de https://cmcenroe.me/2018/12/14/uloc.html donde se presenta el cálculo utilizando herramientas estándar de Unix sort -u *.h *.c | wc -l . Esta métrica está ahí para ayudar con la estimación de la complejidad dentro del proyecto. Citando la fuente
En mi opinión, la cifra que esto produce debería ser una mejor estimación de la complejidad de un proyecto. En comparación con SLOC, no solo se descuentan las líneas en blanco, sino también las líneas entre llaves y otros códigos repetitivos, como las inclusiones comunes. Por otro lado, ULOC cuenta los comentarios, que requieren tanto mantenimiento como el código que los rodea, evitando al mismo tiempo inflar el resultado con encabezados de licencia que aparecen en cada archivo, por ejemplo.
Puede obtener el ULOC proporcionando el argumento -u o --uloc a scc .
Tiene una métrica correspondiente DRYness % que es el porcentaje de ULOC a CLOC o DRYness = ULOC / SLOC . Cuanto mayor sea el número, más SECO (no lo repita) se podrá considerar el proyecto. En general, un valor más alto aquí es mejor ya que indica menos código duplicado. La métrica DRYness fue tomada de un comentario de minimax https://lobste.rs/s/has9r7/uloc_unique_lines_code
Para obtener la métrica DRYness, puede usar el argumento -a o --dryness para scc , que establecerá implícitamente --uloc .
Tenga en cuenta que existe una penalización de rendimiento al calcular las métricas ULOC que puede duplicar el tiempo de ejecución.
Al ejecutar los cálculos de uloc y DRYness con código C, un clon de redis produce el siguiente resultado.
$ 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)
───────────────────────────────────────────────────────────────────────────────
Puede encontrar más información sobre el cálculo de ULOC en https://boyter.org/posts/sloc-cloc-code-new-metic-uloc/
COCOMO
Las estadísticas de COCOMO que se muestran en la parte inferior de cualquier ejecución de línea de comando se pueden configurar según sea necesario.
Estimated Cost to Develop (organic) $664,081
Estimated Schedule Effort (organic) 11.772217 months
Estimated People Required (organic) 5.011633
Para cambiar los parámetros de COCOMO, puede utilizar uno de los modelos COCOMO predeterminados.
scc --cocomo-project-type organic
scc --cocomo-project-type semi-detached
scc --cocomo-project-type embedded
También puede proporcionar sus propios parámetros si está familiarizado con COCOMO de la siguiente manera:
scc --cocomo-project-type "custom,1,1,1,1"
Consulte a continuación para obtener detalles sobre cómo se eligen los modelos y los parámetros que utilizan.
Orgánico: se dice que un proyecto de software es de tipo orgánico si el tamaño del equipo requerido es adecuadamente pequeño, el problema se comprende bien y se ha resuelto en el pasado y además los miembros del equipo tienen una experiencia nominal con respecto al problema.
scc --cocomo-project-type "organic,2.4,1.05,2.5,0.38"
Pareado: se dice que un proyecto de software es del tipo Pareado si las características vitales, como el tamaño del equipo, la experiencia y el conocimiento de los diversos entornos de programación, se encuentran entre lo orgánico y lo integrado. Los proyectos clasificados como Pareados son comparativamente menos familiares y difíciles de desarrollar en comparación con los orgánicos y requieren más experiencia y mejor orientación y creatividad. Ej.: Los compiladores o diferentes Sistemas Embebidos pueden considerarse de tipo Pareado.
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
Integrado: un proyecto de software que requiere el más alto nivel de complejidad, creatividad y experiencia se incluye en esta categoría. Dicho software requiere un equipo más grande que los otros dos modelos y también los desarrolladores deben tener suficiente experiencia y creatividad para desarrollar modelos tan complejos.
scc --cocomo-project-type "embedded,3.6,1.20,2.5,0.32"
Detección de archivos grandes
Puede hacer que scc excluya archivos grandes de la salida.
La opción para hacerlo es --no-large que de forma predeterminada excluirá archivos de más de 1.000.000 bytes o 40.000 líneas.
Puede controlar el tamaño de cualquiera de los valores usando --large-byte-count o --large-line-count .
Por ejemplo, para excluir archivos de más de 1000 líneas y 50 kb, puede utilizar lo siguiente:
scc --no-large --large-byte-count 50000 --large-line-count 1000
Detección de archivos minimizados/generados
Puede hacer que scc identifique y, opcionalmente, elimine los archivos identificados como minificados o generados a partir de la salida.
Puede hacerlo habilitando el indicador -z como scc -z , que identificará cualquier archivo con un tamaño de byte de línea promedio >= 255 (de forma predeterminada) como minificado.
Los archivos minimizados aparecen así en el resultado.
$ 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)
───────────────────────────────────────────────────────────────────────────────
Los archivos minimizados se indican con el texto (min) después del nombre del idioma.
Los archivos generados se indican con el texto (gen) después del nombre del idioma.
Puede controlar el tamaño promedio de bytes de línea usando --min-gen-line-length como scc -z --min-gen-line-length 1 . Tenga en cuenta que necesita -z ya que modificar este valor no implica una detección minimizada.
Puede excluir totalmente los archivos minificados del recuento utilizando la bandera --no-min-gen . Los archivos que coincidan con la verificación minimizada se excluirán del resultado.
Reasignación
Es posible que algunos archivos no tengan extensión. ¡Serán revisados para ver si son un #! archivo. Si es así, el idioma se reasignará al idioma correcto. De lo contrario, no se procesará.
Sin embargo, es posible que tenga la situación en la que desee reasignar dichos archivos en función de una cadena dentro de ellos. Para hacerlo puedes usar --remap-unknown
scc --remap-unknown "-*- C++ -*-":"C Header"
Lo anterior inspeccionará cualquier archivo sin extensión buscando la cadena -*- C++ -*- y, si la encuentra, reasignará el archivo para que se cuente usando las reglas del encabezado C. Puede tener múltiples reglas de reasignación si es necesario,
scc --remap-unknown "-*- C++ -*-":"C Header","other":"Java"
También existe el parámetro --remap-all que reasignará todos los archivos.
Tenga en cuenta que en todos los casos, si la regla de reasignación no se aplica, ¡normal #! se aplicarán las reglas.
Formatos de salida
De forma predeterminada, scc se enviará a la consola. Sin embargo, puede producir resultados en otros formatos si lo necesita.
Las diferentes opciones son tabular, wide, json, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetrics .
Tenga en cuenta que puede escribir la salida scc en el disco usando la opción -o, --output . Esto le permite especificar un archivo para escribir su salida. Por ejemplo, scc -f html -o output.html ejecutará scc en el directorio actual y enviará los resultados en html al archivo output.html .
También puede escribir en varios archivos de salida o en varios tipos en la salida estándar si desea utilizar la opción --format-multi . Esto es más útil cuando se trabaja en sistemas CI/CD donde desea informes HTML como un artefacto y al mismo tiempo mostrar los recuentos en la salida estándar.
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
Lo anterior se ejecutará en el directorio actual, generando en la salida estándar la salida predeterminada, además de escribir en salida.html y salida.csv con los formatos apropiados.
Tabular
Este es el formato de salida predeterminado cuando se ejecuta scc.
Ancho
Wide produce información adicional que es la métrica de complejidad/líneas. Esto puede resultar útil al intentar identificar el archivo más complejo dentro de un proyecto en función de la estimación de complejidad.
JSON
JSON produce una salida JSON. Diseñado principalmente para permitir que scc se incorpore a otros programas.
Tenga en cuenta que este formato le proporcionará el tamaño en bytes de cada archivo que lee scc , lo que le permitirá obtener un desglose del número de bytes procesados.
CSV
CSV como opción es buena para importar a una hoja de cálculo para su análisis.
Tenga en cuenta que este formato le proporcionará el tamaño en bytes de cada archivo que lee scc , lo que le permitirá obtener un desglose del número de bytes procesados. También tenga en cuenta que CSV respeta --by-file y, como tal, devolverá un resumen de forma predeterminada.
Transmisión CSV
csv-stream es una opción útil para procesar repositorios muy grandes donde es probable que se produzcan problemas de memoria. Su formato de salida es 100% igual que CSV.
Tenga en cuenta que no debe usar esto con la opción format-multi ya que siempre imprimirá en salida estándar y, debido a su funcionamiento, anulará el ahorro de memoria que normalmente obtiene. ahorro que proporciona esta opción. Tenga en cuenta que no se aplica ninguna clasificación con esta opción.
cloc-yaml
Es un reemplazo directo de cloc usando su opción de salida yaml. Esto se usa con bastante frecuencia para pasar a otros sistemas de compilación y puede ayudar a reemplazar cloc si es necesario.
$ 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 y TABLA HTML
Las opciones de salida HTML producen un informe html mínimo utilizando una tabla que es html independiente o simplemente como una html-table que se puede insertar en sus propias páginas HTML. La única diferencia entre los dos es que la opción html incluye etiquetas de encabezado y cuerpo html con un estilo mínimo.
El marcado está diseñado para permitir que se apliquen sus propios estilos personalizados. Aquí puede ver un informe de ejemplo.
Tenga en cuenta que las opciones HTML siguen las opciones de la línea de comando, por lo que puede usar scc --by-file -f html para generar un informe con cada archivo y no solo el resumen.
Tenga en cuenta que este formato, si tiene la opción --by-file , le dará el tamaño en bytes de cada archivo que lee scc , lo que le permitirá obtener un desglose del número de bytes procesados.
SQL y SQL-Inserción
El formato de salida SQL "mayormente" compatible con el formato de salida SQL de cloc https://github.com/AlDanial/cloc#sql-
Si bien todas las consultas sobre la documentación de cloc deberían funcionar como se esperaba, no podrá agregar resultados de scc y cloc a la misma base de datos. Esto se debe a que el formato de la tabla es ligeramente diferente para tener en cuenta scc, incluidos los recuentos de complejidad y los bytes.
La diferencia entre sql y sql-insert es que sql incluirá la creación de tablas, mientras que este último solo tendrá los comandos de inserción.
El uso es 100% igual que cualquier otro comando scc , pero la salida SQL siempre contendrá detalles por archivo. Puede calcular los totales usted mismo usando SQL; sin embargo, los cálculos de COCOMO aparecerán en el
