Sloc Cloc e Código (scc)
Uma ferramenta semelhante a cloc, sloccount e tokei. Para contar linhas de código, linhas em branco, linhas de comentários e linhas físicas de código-fonte em muitas linguagens de programação.
O objetivo é ser o contador de código mais rápido possível, mas também realizar cálculos COCOMO como sloccount, estimar a complexidade do código semelhante às calculadoras de complexidade ciclomática e produzir linhas de código exclusivas ou métricas de DRYness. Resumindo, uma ferramenta para governar todos eles.
Também tem um nome muito curto que é fácil de digitar scc .
Se você não gosta de sloc cloc e código, sinta-se à vontade para usar o nome Succinct Code Counter .
Licenciado sob licença do MIT.
Índice
Apoiar
Instalar
Fundo
Tom
Uso
Estimativas de Complexidade
Linhas de código exclusivas (ULOC)
COCOMO
Formatos de saída
Desempenho
Desenvolvimento
Adicionando/Modificando Idiomas
Problemas
Selos (beta)
Suporte a idiomas
Apoiar
Usando scc comercialmente? Se você deseja suporte prioritário para scc você pode adquirir um ano no valor de https://boyter.gumroad.com/l/kgenuv, que lhe dá direito a suporte prioritário direto por e-mail do desenvolvedor.
Instalar
Vá instalar
Você pode instalar scc usando o conjunto de ferramentas go padrão.
Para instalar a versão estável mais recente do scc:
go install github.com/boyter/scc/v3@latest
Para instalar uma versão de desenvolvimento:
go install github.com/boyter/scc/v3@master
Observe que scc precisa da versão >= 1.22.
Foto
Existe uma instalação instantânea graças a Ricardo.
$ sudo snap install scc
NB Os aplicativos instalados no Snap não podem ser executados fora de /home https://askubuntu.com/questions/930437/permission-denied-error-when-running-apps-installed-as-snap-packages-ubuntu-17, então você pode encontrar problemas se você usar o snap e tentar executar fora deste diretório.
Cerveja caseira
Ou se você tiver o Homebrew instalado
$ brew install scc
MacPorts
No macOS, você também pode instalar via MacPorts
$ sudo port install scc
Colher
Ou se você estiver usando o Scoop no Windows
$ scoop install scc
Chocolate
Ou se você estiver usando Chocolatey no Windows
$ choco install scc
WinGet
Ou se você estiver usando WinGet no Windows
winget install --id benboyter.scc --source winget
FreeBSD
No FreeBSD, scc está disponível como um pacote
$ pkg install scc
Ou, se preferir compilar a partir do código-fonte, você pode usar a árvore de ports
$ cd /usr/ports/devel/scc && make install clean
Execute no Docker
Vá para o diretório a partir do qual deseja executar o scc.
Execute o comando abaixo para executar a versão mais recente do scc em seu diretório de trabalho atual:
docker run --rm -it -v "$PWD:/pwd" ghcr.io/lhoupert/scc:master scc /pwd
Manual
Binários para Windows, GNU/Linux e macOS para máquinas i386 e x86_64 estão disponíveis na página de lançamentos.
GitLab
https://about.gitlab.com/blog/2023/02/15/code-counting-in-gitlab/
Outro
Se você gostaria de ajudar a adicionar scc ao apt/chocolatey/etc... envie um PR ou pelo menos levante um problema com instruções.
Fundo
Leia tudo sobre como isso surgiu junto com os benchmarks de desempenho,
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/
Algumas avaliações sobre 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
Uma palestra proferida na primeira GopherCon AU sobre scc (pressione S para ver as notas do palestrante)
Para desempenho, consulte a seção Desempenho
Outros projetos semelhantes,
SLOCCount o contador sloc original
cloc, inspirado em SLOCCount; implementado em Perl para portabilidade
gocloc um contador sloc em Go inspirado em tokei
implementação de ferrugem loc semelhante ao tokei, mas geralmente mais rápida
Implementação loccount Go escrita e mantida pela ESR
contador de sloc ATS poliglota
tokei rápido, preciso e escrito em ferrugem
contador de código sloc coffeescript
novo contador de código Go com foco no desempenho
Leitura interessante sobre outros projetos de contagem de código tokei, loc, polyglot e 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
Leitura adicional sobre o processamento de arquivos no desempenho do disco
Usando scc para processar 40 TB de arquivos do GitHub/Bitbucket/GitLab
Tom
Por que usar scc ?
É muito rápido e fica mais rápido quanto mais CPU você usa nele
Preciso
Funciona muito bem em múltiplas plataformas sem lentidão (Windows, Linux, macOS)
Grande suporte a idiomas
Pode ignorar arquivos duplicados
Tem estimativas de complexidade
Você precisa saber a diferença entre Coq e Verilog no mesmo diretório
suporte à saída cloc yaml, potencialmente uma substituição para alguns usuários
Pode identificar ou ignorar arquivos minificados
Capaz de identificar muitos #! arquivos AVANÇADO! #115
Pode ignorar arquivos grandes por linhas ou bytes
Pode calcular o ULOC ou linhas únicas de código por arquivo, linguagem ou projeto
Suporta vários formatos de saída para integração, CSV, SQL, JSON, HTML e muito mais
Por que não usar scc ?
Diferenças
Existem algumas diferenças importantes entre scc e outras ferramentas existentes. Aqui estão alguns importantes para você considerar.
As linhas em branco dentro dos comentários são contadas como comentários. Embora a linha esteja tecnicamente em branco, foi tomada a decisão de que, uma vez incluído em um comentário, tudo o que existe deve ser considerado um comentário até que esse comentário seja encerrado. Como tal, o seguinte,
/* blank lines follow
*/
Seria contado como 4 linhas de comentários. Isso é perceptível ao comparar a saída do scc com outras ferramentas em grandes repositórios.
scc é capaz de contar strings literais corretamente. Por exemplo, em C# o seguinte,
private const string BasePath = @"a:";
// The below is returned to the user as a version
private const string Version = "1.0.0";
Por causa do prefixo @, esta string termina no final ", ignorando o caractere de escape e, como tal, deve ser contada como 2 linhas de código e 1 comentário. Algumas ferramentas são incapazes de lidar com isso e, em vez disso, contam até "1.0.0" como uma string que pode fazer com que o comentário do meio seja contado como código em vez de um comentário.
scc também informará o número de bytes processados (para a maioria dos formatos de saída), permitindo estimar o custo de execução de algumas ferramentas de análise estática.
Uso
O uso da linha de comando do scc foi projetado para ser o mais simples possível. Detalhes completos podem ser encontrados em scc --help ou scc -h . Observe que o texto abaixo reflete o estado do master e não de uma versão, pois os recursos listados abaixo podem estar faltando em sua instalação.
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)
A saída deve ser semelhante à mostrada abaixo para o projeto 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)
───────────────────────────────────────────────────────────────────────────────
Observe que você não precisa especificar o diretório no qual deseja executar. A execução scc assumirá que você deseja executar no diretório atual.
Você também pode executar em vários arquivos ou diretórios scc directory1 directory2 file1 file2 com os resultados agregados na saída.
Como scc grava na saída padrão, há muitas maneiras de compartilhar facilmente os resultados. Por exemplo, usar netcat e um dos muitos pastebins fornece uma URL pública:
$ scc | nc paste.c-net.org 9999
https://paste.c-net.org/Example
Ignorar arquivos
scc suporta principalmente arquivos .ignore dentro dos diretórios que ele verifica. Isso é semelhante ao funcionamento de ripgrep, ag e tokei. Os arquivos .ignore são 100% iguais aos arquivos .gitignore com a mesma sintaxe e, como tal, scc ignorará os arquivos e diretórios listados neles. Você pode adicionar arquivos .ignore para ignorar coisas como dependência de fornecedor verificada em arquivos e outros. A ideia é permitir que você adicione um arquivo ou pasta ao git e ignore na contagem.
Ele também suporta seu próprio arquivo ignorado .sccignore se você quiser que scc ignore coisas enquanto ripgrep, ag, tokei e outros os suportam.
Casos de uso interessantes
Usado dentro do hipervisor Intel Nemu para rastrear alterações de código entre revisões https://github.com/intel/nemu/blob/topic/virt-x86/tools/cloc-change.sh#L9 Parece também ser usado dentro de http:/ /codescoop.com/ https://pinpoint.com/ https://github.com/chaoss/grimoirelab-graal
Ele também é usado para contar códigos e adivinhar tipos de linguagem em https://searchcode.com/, o que o torna um dos contadores de código executados com mais frequência no mundo.
Você também pode conectar o scc ao pipeline do gitlab https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-scc
Também usado por CodeQL #317 e Scaleway https://twitter.com/Scaleway/status/1488087029476995074?s=20&t=N2-z6O-ISDdDzULg4o4uVQ
Características
scc usa uma pequena máquina de estado para determinar em que estado o código está quando atinge uma nova linha n . Como tal, está ciente e é capaz de contar
Por causa disso, ele é capaz de determinar com precisão se um comentário está em uma string ou se é realmente um comentário.
Também tenta contar a complexidade do código. Isso é feito verificando operações de ramificação no código. Por exemplo, cada um dos seguintes for if switch while else || && != == se encontrado em Java aumentaria a complexidade dos arquivos em um.
Estimativas de Complexidade
Vamos dedicar um minuto para discutir a estimativa de complexidade em si.
A estimativa de complexidade é, na verdade, apenas um número comparável apenas a arquivos no mesmo idioma. Não deve ser usado para comparar idiomas diretamente sem ponderá-los. A razão para isso é que ele é calculado procurando instruções de ramificação e loop no código e incrementando um contador para esse arquivo.
Como algumas linguagens não possuem loops e, em vez disso, usam recursão, elas podem ter uma contagem de complexidade menor. Isso significa que eles são menos complexos? Provavelmente não, mas a ferramenta não consegue ver isso porque não cria um AST do código, pois apenas o verifica.
Geralmente, embora a complexidade exista para ajudar a estimar entre projetos escritos na mesma linguagem ou para encontrar o arquivo mais complexo em um projeto scc --by-file -s complexity que pode ser útil quando você está estimando o quão difícil é algo manter, ou ao procurar por arquivos que provavelmente deveriam ser refatorados.
Quanto a como funciona.
É minha própria definição, mas tenta ser uma aproximação da complexidade ciclomática https://en.wikipedia.org/wiki/Cyclomatic_complexity, embora feita apenas no nível do arquivo.
A razão pela qual é uma aproximação é que ela é calculada quase de graça do ponto de vista da CPU (já que é uma pesquisa barata durante a contagem), enquanto uma contagem de complexidade ciclomática real precisaria analisar o código. Ele fornece uma estimativa razoável na prática, mesmo que não consiga identificar métodos recursivos. O objetivo nunca foi que fosse exato.
Resumindo, quando o scc estiver examinando o que identificou como código, se perceber o que geralmente são condições de ramificação, ele incrementará um contador.
As condições que ele procura são compiladas no código e você pode ter uma ideia delas olhando o JSON dentro do repositório. Consulte https://github.com/boyter/scc/blob/master/languages.json#L3869 para obter um exemplo do que está procurando em um arquivo Java.
O incremento acontece para cada uma das condições correspondentes e produz o número que você vê.
Linhas de código exclusivas (ULOC)
ULOC significa Unique Lines of Code e representa as linhas exclusivas entre linguagens, arquivos e o próprio projeto. Esta ideia foi retirada de https://cmcenroe.me/2018/12/14/uloc.html onde o cálculo é apresentado usando ferramentas padrão do Unix sort -u *.h *.c | wc -l . Essa métrica existe para auxiliar na estimativa da complexidade do projeto. Citando a fonte
Na minha opinião, o número que isso produz deveria ser uma estimativa melhor da complexidade de um projeto. Em comparação com o SLOC, não apenas as linhas em branco são descontadas, mas também as linhas entre colchetes e outros códigos repetitivos, como inclusões comuns. Por outro lado, o ULOC conta comentários, que requerem tanta manutenção quanto o código ao seu redor, evitando inflar o resultado com cabeçalhos de licença que aparecem em cada arquivo, por exemplo.
Você pode obter o ULOC fornecendo o argumento -u ou --uloc para scc .
Possui uma métrica correspondente DRYness % que é a porcentagem de ULOC para CLOC ou DRYness = ULOC / SLOC . Quanto maior o número, mais SECO (não se repita) o projeto pode ser considerado. Em geral, um valor mais alto aqui é melhor, pois indica menos código duplicado. A métrica DRYness foi obtida de um comentário de minimax https://lobste.rs/s/has9r7/uloc_unique_lines_code
Para obter a métrica DRYness você pode usar o argumento -a ou --dryness para scc , que definirá implicitamente --uloc .
Observe que há uma penalidade de desempenho ao calcular as métricas ULOC que podem dobrar o tempo de execução.
Executando os cálculos uloc e DRYness no código C, um clone do redis produz uma saída como segue.
$ 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)
───────────────────────────────────────────────────────────────────────────────
Leitura adicional sobre o cálculo ULOC pode ser encontrada em https://boyter.org/posts/sloc-cloc-code-new-metic-uloc/
COCOMO
As estatísticas do COCOMO exibidas na parte inferior de qualquer execução de linha de comando podem ser configuradas conforme necessário.
Estimated Cost to Develop (organic) $664,081
Estimated Schedule Effort (organic) 11.772217 months
Estimated People Required (organic) 5.011633
Para alterar os parâmetros COCOMO, você pode usar um dos modelos COCOMO padrão.
scc --cocomo-project-type organic
scc --cocomo-project-type semi-detached
scc --cocomo-project-type embedded
Você também pode fornecer seus próprios parâmetros se estiver familiarizado com o COCOMO da seguinte forma,
scc --cocomo-project-type "custom,1,1,1,1"
Veja abaixo detalhes sobre como são feitas as escolhas do modelo e os parâmetros que eles usam.
Orgânico – Um projeto de software é considerado do tipo orgânico se o tamanho da equipe necessária for adequadamente pequeno, o problema for bem compreendido e tiver sido resolvido no passado e também os membros da equipe tiverem uma experiência nominal em relação ao problema.
scc --cocomo-project-type "organic,2.4,1.05,2.5,0.38"
Geminado - Um projeto de software é considerado do tipo Semi-destacado se as características vitais, como tamanho da equipe, experiência, conhecimento dos diversos ambientes de programação, estiverem entre orgânico e incorporado. Os projetos classificados como Geminados são comparativamente menos familiares e difíceis de desenvolver em comparação com os orgânicos e requerem mais experiência e melhor orientação e criatividade. Ex.: Compiladores ou diferentes Sistemas Embarcados podem ser considerados do tipo Semi-Separados.
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"
Incorporado - Um projeto de software que exige o mais alto nível de complexidade, criatividade e experiência se enquadra nesta categoria. Esse software requer uma equipe maior do que os outros dois modelos e também os desenvolvedores precisam ser suficientemente experientes e criativos para desenvolver modelos tão complexos.
scc --cocomo-project-type "embedded,3.6,1.20,2.5,0.32"
Detecção de arquivos grandes
Você pode fazer com que scc exclua arquivos grandes da saída.
A opção para fazer isso é --no-large que por padrão excluirá arquivos com mais de 1.000.000 bytes ou 40.000 linhas.
Você pode controlar o tamanho de qualquer valor usando --large-byte-count ou --large-line-count .
Por exemplo, para excluir arquivos com mais de 1.000 linhas e 50 KB, você pode usar o seguinte:
scc --no-large --large-byte-count 50000 --large-line-count 1000
Detecção de arquivos minimizados/gerados
Você pode fazer com que scc identifique e, opcionalmente, remova os arquivos identificados como minificados ou gerados a partir da saída.
Você pode fazer isso habilitando o sinalizador -z como scc -z que identificará qualquer arquivo com tamanho médio de bytes de linha >= 255 (por padrão) como sendo minificado.
Os arquivos minimizados aparecem assim na saída.
$ 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)
───────────────────────────────────────────────────────────────────────────────
Os arquivos reduzidos são indicados com o texto (min) após o nome do idioma.
Os arquivos gerados são indicados com o texto (gen) após o nome do idioma.
Você pode controlar o tamanho médio de bytes da linha usando --min-gen-line-length como scc -z --min-gen-line-length 1 . Observe que você precisa -z , pois a modificação deste valor não implica detecção reduzida.
Você pode excluir totalmente os arquivos minificados da contagem usando o sinalizador --no-min-gen . Os arquivos que correspondem à verificação minificada serão excluídos da saída.
Remapeamento
Alguns arquivos podem não ter extensão. Eles serão verificados para ver se são #! arquivo. Se estiverem, o idioma será remapeado para o idioma correto. Caso contrário, não será processado.
No entanto, você pode ter a situação em que deseja remapear esses arquivos com base em uma string dentro deles. Para fazer isso você pode usar --remap-unknown
scc --remap-unknown "-*- C++ -*-":"C Header"
O acima irá inspecionar qualquer arquivo sem extensão procurando pela string -*- C++ -*- e se encontrado remapear o arquivo a ser contado usando as regras do cabeçalho C. Você pode ter várias regras de remapeamento, se necessário,
scc --remap-unknown "-*- C++ -*-":"C Header","other":"Java"
Há também o parâmetro --remap-all que remapeará todos os arquivos.
Observe que em todos os casos, se a regra de remapeamento não se aplicar ao #! regras serão aplicadas.
Formatos de saída
Por padrão, scc será enviado para o console. No entanto, você pode produzir saída em outros formatos, se desejar.
As diferentes opções são tabular, wide, json, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetrics .
Observe que você pode gravar a saída scc no disco usando a opção -o, --output . Isso permite que você especifique um arquivo no qual gravar sua saída. Por exemplo, scc -f html -o output.html executará scc no diretório atual e enviará os resultados em html para o arquivo output.html .
Você também pode gravar em vários arquivos de saída ou em vários tipos em stdout, se desejar, usando a opção --format-multi . Isso é mais útil ao trabalhar em sistemas CI/CD onde você deseja relatórios HTML como um artefato e ao mesmo tempo exibir as contagens em stdout.
scc --format-multi "tabular:stdout,html:output.html,csv:output.csv"
O procedimento acima será executado no diretório atual, enviando para a saída padrão a saída padrão, bem como gravando em output.html e output.csv com os formatos apropriados.
Tabular
Este é o formato de saída padrão quando o scc é executado.
Largo
Wide produz algumas informações adicionais que são a métrica de complexidade/linhas. Isto pode ser útil ao tentar identificar o arquivo mais complexo dentro de um projeto com base na estimativa de complexidade.
JSON
JSON produz saída JSON. Projetado principalmente para permitir que scc seja inserido em outros programas.
Observe que este formato fornecerá o tamanho de bytes de cada leitura de arquivo scc permitindo que você obtenha um detalhamento do número de bytes processados.
CSV
O CSV como opção é bom para importar para uma planilha para análise.
Observe que este formato fornecerá o tamanho de bytes de cada leitura de arquivo scc permitindo que você obtenha um detalhamento do número de bytes processados. Observe também que o CSV respeita --by-file e, como tal, retornará um resumo por padrão.
Fluxo CSV
csv-stream é uma opção útil para processar repositórios muito grandes onde é provável que você encontre problemas de memória. Seu formato de saída é 100% igual ao CSV.
Observe que você não deve usar isso com a opção format-multi , pois ela sempre imprimirá na saída padrão e, devido à forma como funciona, anulará a economia de memória que normalmente ganha. poupança que esta opção proporciona. Observe que não há classificação aplicada com esta opção.
cloc-yaml
É um substituto para cloc usando sua opção de saída yaml. Isso é frequentemente usado para passar para outros sistemas de construção e pode ajudar na substituição do cloc, se necessário.
$ 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 e HTML-TABELA
As opções de saída HTML produzem um relatório HTML mínimo usando uma tabela que é html independente ou apenas uma html-table que pode ser injetada em suas próprias páginas HTML. A única diferença entre os dois é que a opção html inclui tags de cabeçalho e corpo html com estilo mínimo.
A marcação foi projetada para permitir que seus próprios estilos personalizados sejam aplicados. Um exemplo de relatório está aqui para visualização.
Observe que as opções HTML seguem as opções da linha de comando, então você pode usar scc --by-file -f html para produzir um relatório com cada arquivo e não apenas o resumo.
Observe que este formato, se tiver a opção --by-file , fornecerá o tamanho de bytes de cada leitura de arquivo scc permitindo que você obtenha um detalhamento do número de bytes processados.
SQL e SQL-Insert
O formato de saída SQL é "principalmente" compatível com o formato de saída SQL do cloc https://github.com/AlDanial/cloc#sql-
Embora todas as consultas na documentação do cloc devam funcionar conforme o esperado, você não poderá anexar a saída de scc e cloc no mesmo banco de dados. Isso ocorre porque o formato da tabela é um pouco diferente para contabilizar scc, incluindo contagens de complexidade e bytes.
A diferença entre sql e sql-insert é que sql incluirá a criação de tabelas enquanto o último terá apenas os comandos de inserção.
O uso é 100% igual a qualquer outro comando scc , mas a saída sql sempre conterá detalhes por arquivo. Você mesmo pode calcular os totais usando SQL, mas os cálculos COCOMO aparecerão em relação ao
