A
ferramenta de linha de comando
Sloc Cloc e Code (scc) que eu escrevi , que agora é finalizada e suportada por muitas pessoas excelentes, conta linhas de código, comentários e avalia a complexidade dos arquivos dentro de um diretório. Uma boa seleção é necessária aqui. A ferramenta conta operadores de ramificação no código. Mas o que é complexidade? Por exemplo, a declaração "Este arquivo tem dificuldade 10" não é muito útil sem contexto. Para resolver esse problema, executei o
scc em todas as fontes da Internet. Isso também permitirá que você encontre alguns casos extremos que não considerei na própria ferramenta. Poderoso teste de força bruta.
Mas se eu for executar o teste em todas as fontes do mundo, isso exigirá muitos recursos de computação, o que também é uma experiência interessante. Por isso, decidi escrever tudo - e este artigo apareceu.
Em resumo, baixei e processei muitas fontes.
Figuras nuas:
- 9.985.051 total de repositórios
- 9.100.083 repositórios com pelo menos um arquivo
- 884 968 repositórios vazios (sem arquivos)
- 3.500.000.000 de arquivos em todos os repositórios
- Processado 40 736 530 379 778 bytes (40 TB)
- 1.086.723.618.560 linhas identificadas
- 816.822.273.469 linhas com código reconhecido
- 124 382 152 510 linhas em branco
- 145 519 192 581 linhas de comentários
- Complexidade total de acordo com as regras scc: 71 884 867 919
- 2 novos bugs encontrados no scc
Vamos apenas mencionar um detalhe. Não há 10 milhões de projetos, conforme indicado no título de alto perfil. Eu perdi 15.000, então completei. Peço desculpas por isso.
Demorou cerca de cinco semanas para baixar tudo, passar pelo scc e salvar todos os dados. Depois, pouco mais de 49 horas para processar 1 TB JSON e obter os resultados abaixo.
Observe também que eu poderia estar enganado em alguns cálculos. Informarei imediatamente se algum erro for detectado e fornecerei um conjunto de dados.
Sumário
Metodologia
Desde o lançamento do
searchcode.com, eu já acumulei uma coleção de mais de 7.000.000 de projetos no git, mercurial, subversion e assim por diante. Então, por que não processá-los? Trabalhar com o git geralmente é a solução mais fácil, então desta vez eu ignorei o mercurial e o subversion e exportei uma lista completa de projetos do git. Acontece que eu realmente acompanhei 12 milhões de repositórios git e provavelmente preciso atualizar a página principal para refletir isso.
Então agora eu tenho 12 milhões de repositórios git para baixar e processar.
Ao executar o scc, você pode selecionar a saída no JSON salvando o arquivo no disco:
scc --format json --output myfile.json main.go Os resultados são os seguintes (para um único arquivo):
[ { "Blank": 115, "Bytes": 0, "Code": 423, "Comment": 30, "Complexity": 40, "Count": 1, "Files": [ { "Binary": false, "Blank": 115, "Bytes": 20396, "Callback": null, "Code": 423, "Comment": 30, "Complexity": 40, "Content": null, "Extension": "go", "Filename": "main.go", "Hash": null, "Language": "Go", "Lines": 568, "Location": "main.go", "PossibleLanguages": [ "Go" ], "WeightedComplexity": 0 } ], "Lines": 568, "Name": "Go", "WeightedComplexity": 0 } ]
Para um exemplo maior, consulte os resultados para o projeto redis:
redis.json . Todos os resultados abaixo são obtidos com esse resultado sem dados adicionais.
Deve-se ter em mente que o scc geralmente classifica os idiomas com base na extensão (a menos que a extensão seja comum, como Verilog e Coq). Portanto, se você salvar um arquivo HTML com a extensão java, ele será considerado um arquivo java. Isso geralmente não é um problema, porque por que fazer isso? Mas, é claro, em larga escala, o problema se torna perceptível. Descobri isso mais tarde, quando alguns arquivos foram disfarçados como uma extensão diferente.
Algum tempo atrás, escrevi um
código para gerar tags github baseadas em scc . Como o processo precisava armazenar em cache os resultados, eu o alterei um pouco para armazená-los no formato JSON no AWS S3.
Com o código para rótulos na AWS no lambda, peguei uma lista exportada de projetos, escrevi cerca de 15 linhas de python para limpar o formato correspondente ao meu lambda e fiz uma solicitação. Usando o multiprocessamento python, paralelizei solicitações a 32 processos para que o terminal respondesse com rapidez suficiente.
Tudo funcionou de maneira brilhante. No entanto, o problema estava, primeiramente, no custo e, em segundo lugar, o lambda tem um tempo limite de 30 segundos para o API Gateway / ALB, portanto, não pode processar repositórios grandes com rapidez suficiente. Eu sabia que essa não era a solução mais econômica, mas pensei que o preço seria de cerca de US $ 100, o que eu suportaria. Depois de processar um milhão de repositórios, verifiquei - e o custo foi de cerca de US $ 60. Como não estava satisfeito com a perspectiva de uma conta final da AWS de US $ 700, decidi reconsiderar minha decisão. Lembre-se de que este era basicamente o armazenamento e a CPU que eram usados para coletar todas essas informações. Qualquer processamento e exportação de dados aumentou significativamente o preço.
Como eu já estava na AWS, uma solução rápida seria despejar os URLs como mensagens no SQS e retirá-los usando instâncias EC2 ou Fargate para processamento. Então escala como um louco. Mas, apesar da experiência cotidiana da AWS, sempre acreditei nos
princípios da programação da Taco Bell . Além disso, havia apenas 12 milhões de repositórios, então decidi implementar uma solução mais simples (mais barata).
Não foi possível iniciar o cálculo localmente devido à terrível internet na Austrália. No entanto, meu searchcode.com funciona usando os servidores dedicados da Hetzner com cuidado. Estas são máquinas bastante potentes de RAM i7 Quad Core de 32 GB, geralmente com 2 TB de espaço de armazenamento (geralmente não usado). Eles geralmente têm um bom suprimento de energia de computação. Por exemplo, o servidor front-end na maioria das vezes calcula a raiz quadrada de zero. Então, por que não começar a processar lá?
Essa não é realmente a programação do Taco Bell, pois usei as ferramentas bash e gnu. Eu escrevi um
programa simples no Go para executar 32 rotinas go que lêem dados de um canal, geram subprocessos git e scc antes de gravar a saída no JSON no S3. Na verdade, eu escrevi a solução primeiro em Python, mas a necessidade de instalar dependências de pip no meu servidor limpo parecia uma má idéia, e o sistema travou de maneiras estranhas que eu não queria depurar.
A execução de tudo isso no servidor produziu as seguintes métricas no htop, e vários processos em execução git / scc (scc não aparece nesta captura de tela) assumiram que tudo estava funcionando conforme o esperado, o que foi confirmado pelos resultados no S3.
Apresentação e cálculo de resultados
Li recentemente
esses artigos , por isso tive a ideia de emprestar o formato desses posts em relação à apresentação de informações. No entanto, eu também queria adicionar o
jQuery DataTables a tabelas grandes para classificar e pesquisar / filtrar os resultados. Assim, no
artigo original, você pode clicar nos títulos para classificar e usar o campo de pesquisa para filtrar.
O tamanho dos dados que precisavam ser processados levantou outra questão. Como processar 10 milhões de arquivos JSON, ocupando pouco mais de 1 TB de espaço em disco no bucket S3?
O primeiro pensamento foi o AWS Athena. Mas como custaria algo como US $ 2,50
por consulta para esse conjunto de dados, rapidamente comecei a procurar uma alternativa. No entanto, se você salvar os dados lá e raramente processá-los, talvez seja a solução mais barata.
Postei uma pergunta no bate-papo corporativo (por que resolver problemas sozinho).
Uma idéia era despejar dados em um grande banco de dados SQL. No entanto, isso significa processar os dados no banco de dados e, em seguida, executar consultas nele várias vezes. Além disso, a estrutura de dados significa várias tabelas, o que significa chaves e índices estrangeiros para fornecer um certo nível de desempenho. Isso parece um desperdício, porque poderíamos apenas processar os dados enquanto os lemos do disco - de uma só vez. Eu também estava preocupado em criar um banco de dados tão grande. Somente com dados, ele terá mais de 1 TB de tamanho antes de adicionar índices.
Vendo como eu criei o JSON de uma maneira simples, pensei: por que não processar os resultados da mesma maneira? Claro, há um problema. Obter 1 TB de dados do S3 custará muito. Se o programa travar, será irritante. Para reduzir custos, eu queria retirar todos os arquivos localmente e salvá-los para processamento adicional. Um bom conselho: é melhor não armazenar
muitos arquivos pequenos em um diretório . Isso é péssimo para o desempenho em tempo de execução, e os sistemas de arquivos não gostam disso.
Minha resposta para isso foi outro
programa Go simples para extrair arquivos do S3 e salvá-los em um arquivo tar. Então eu poderia processar esse arquivo repetidamente. O processo em si executa um
programa Go muito feio para processar o arquivo tar, para que eu possa executar novamente as consultas sem precisar extrair dados do S3 repetidamente. Não me preocupei com as rotinas aqui por dois motivos. Primeiramente, eu não queria carregar o servidor o máximo possível, então me limitei a um núcleo para a CPU trabalhar duro (o outro estava bloqueado no processador para ler o arquivo tar). Em segundo lugar, eu queria garantir a segurança do thread.
Quando isso foi feito, era necessário um conjunto de perguntas para responder. Novamente usei a mente coletiva e conectei meus colegas enquanto tive minhas próprias idéias. O resultado dessa fusão de mentes é apresentado abaixo.
Você pode encontrar
todo o código que eu usei para processar JSON, incluindo o código para processamento local, e o
script Python feio que eu usei para preparar algo útil para este artigo: por favor, não comente, eu sei que o código é feio , e está escrito para uma tarefa única, pois é improvável que eu o veja novamente.
Se você quiser ver o código que escrevi para uso geral, consulte as
fontes scc .
Custo
Gastei cerca de US $ 60 em computação enquanto tentava trabalhar com o lambda. Ainda não analisei o custo de armazenamento do S3, mas ele deve estar perto de US $ 25, dependendo do tamanho dos dados. No entanto, isso não inclui os custos de transmissão, os quais eu também não assisti. Observe que limpei o balde quando o terminei, portanto, este não é um custo fixo.
Mas depois de um tempo ainda abandonei a AWS. Então, qual é o custo real se eu quiser fazê-lo novamente?
Todo o software que temos é gratuito e gratuito. Portanto, não há nada com que se preocupar.
No meu caso, o custo seria zero, pois usei o poder de computação "gratuito" deixado no searchcode.com. No entanto, nem todo mundo tem esses recursos gratuitos. Portanto, vamos supor que a outra pessoa queira repetir isso e precise aumentar o servidor.
Isso pode ser feito por 73 € usando o novo
servidor dedicado mais barato
da Hetzner , incluindo o custo de instalação de um novo servidor. Se você esperar e se aprofundar na
seção com leilões , poderá encontrar servidores muito mais baratos sem taxas de instalação. No momento em que escrevi, encontrei um carro perfeito para este projeto, por 25,21 euros por mês sem taxas de instalação.
O que é ainda melhor: fora da União Europeia, o IVA será removido desse preço. Portanto, fique à vontade para aproveitar outros 10%.
Portanto, se você levantar esse serviço do zero no meu software, ele custará até US $ 100, mas até US $ 50, se você for um pouco paciente ou bem-sucedido. Isso pressupõe que você esteja usando o servidor há menos de dois meses, o que é suficiente para baixar e processar. Também há tempo suficiente para obter uma lista de 10 milhões de repositórios.
Se eu usasse o tar compactado (o que na verdade não é tão difícil), poderia processar 10 vezes mais repositórios na mesma máquina, e o arquivo resultante ainda será pequeno o suficiente para caber no mesmo HDD. Embora o processo possa demorar vários meses, porque o download levará mais tempo.
Para ir muito além dos 100 milhões de repositórios, no entanto, é necessário algum tipo de sharding. No entanto, é seguro dizer que você repetirá o processo em minha escala ou muito maior, no mesmo equipamento sem muito esforço ou alterações de código.
Fontes de dados
Veja quantos projetos vieram de cada uma das três fontes: github, bitbucket e gitlab. Observe que isso é antes de excluir repositórios vazios; portanto, a quantidade excede o número de repositórios que são realmente processados e levados em consideração nas tabelas a seguir.
Peço desculpas à equipe do GitHub / Bitbucket / GitLab, se você ler isso. Se meu script causou algum problema (embora eu duvide), tomo uma bebida de sua escolha quando me encontrar.
Quantos arquivos existem no repositório?
Vamos passar para os problemas reais. Vamos começar com um simples. Quantos arquivos existem no repositório médio? A maioria dos projetos tem apenas alguns arquivos ou mais? Após percorrer os repositórios, obtemos o seguinte cronograma:
Aqui, o eixo x mostra os intervalos com o número de arquivos e o eixo y mostra o número de projetos com tantos arquivos. Limite o eixo horizontal a mil arquivos, pois o gráfico está muito próximo do eixo.
Parece que a maioria dos repositórios tem menos de 200 arquivos.
Mas e a visualização até o percentil 95, que mostrará a imagem real? Acontece que na grande maioria (95%) dos projetos - menos de 1000 arquivos. Enquanto 90% dos projetos têm menos de 300 arquivos e 85% têm menos de 200.
Se você deseja criar um gráfico e fazê-lo melhor do que eu, aqui está um
link para os dados brutos no JSON .
Qual é a quebra de idioma?
Por exemplo, se um arquivo Java for identificado, aumentamos o número de Java nos projetos em um e não fazemos nada para o segundo arquivo. Isso dá uma idéia rápida de quais idiomas são mais usados. Não é novidade que os idiomas mais comuns incluem markdown, .gitignore e plaintext.
Markdown é o idioma mais usado; é visto em mais de 6 milhões de projetos, o que representa cerca de 2⁄3 do total. Isso faz sentido, já que quase todos os projetos incluem o README.md, que é exibido em HTML para as páginas do repositório.
Quantos arquivos existem no repositório por idioma?
Adição à tabela anterior, mas média do número de arquivos para cada idioma no repositório. Ou seja, quantos arquivos Java existem em média para todos os projetos em que existe Java?
Quantas linhas de código em um arquivo de idioma típico?
Suponho que ainda seja interessante ver quais idiomas têm os maiores arquivos em média? O uso da média aritmética gera números anormalmente altos devido a projetos como o sqlite.c, que está incluído em muitos repositórios, combinando muitos arquivos em um, mas ninguém trabalha nesse único arquivo grande (espero!).Portanto, calculei a média da mediana. No entanto, idiomas com valores absurdamente altos, como Bosque e JavaScript, ainda permaneciam.Então pensei: por que não fazer um movimento de cavaleiro? Por sugestão de Darrell (um residente de Kablamo e um excelente cientista de dados), fiz uma pequena alteração e mudei a média aritmética, largando arquivos em mais de 5.000 linhas para remover anomalias.Média de complexidade do arquivo em cada idioma?
Qual é a complexidade média do arquivo para cada idioma?De fato, as classificações de complexidade não podem ser diretamente correlacionadas entre os idiomas. Trecho do próprio leia-me scc:A pontuação de complexidade é apenas um número que só pode ser correspondido entre arquivos no mesmo idioma. Não deve ser usado para comparar idiomas diretamente. O motivo é que ele é calculado procurando operadores de ramificação e loop para cada arquivo.
Assim, as linguagens não podem ser comparadas aqui, embora isso possa ser feito entre linguagens semelhantes, como Java e C, por exemplo.Essa é uma métrica mais valiosa para arquivos individuais no mesmo idioma. Assim, você pode responder à pergunta "Este arquivo com o qual estou trabalhando é mais fácil ou mais difícil que a média?"Devo mencionar que ficarei feliz com as sugestões para melhorar essa métrica no scc . Para uma confirmação, geralmente é suficiente adicionar apenas algumas palavras-chave ao arquivo languages.json, para que qualquer programador possa ajudar.Número médio de comentários para arquivos em cada idioma?
Qual é o número médio de comentários nos arquivos em cada idioma?Talvez a questão possa ser reformulada: os desenvolvedores em que idioma escrevem mais comentários, sugerindo um mal-entendido do leitor.Quais são os nomes de arquivos mais comuns?
Quais nomes de arquivos são mais comuns em todas as bases de código, ignorando extensão e maiúsculas e minúsculas?Se você me perguntasse anteriormente, eu diria: README, main, index, license. Os resultados refletem muito bem minhas suposições. Embora haja muitas coisas interessantes. Não faço ideia por que tantos projetos contêm um arquivo chamado 15or s15.O makefile mais comum me surpreendeu um pouco, mas lembrei que ele era usado em muitos novos projetos JavaScript. Outra coisa interessante a ser observada: parece que o jQuery ainda está no cavalo, e os relatos de sua morte são muito exagerados, e ele está em quarto lugar na lista.Observe que, devido a limitações de memória, tornei esse processo um pouco menos preciso. Após cada 100 projetos, verifiquei o mapa e excluí os nomes dos arquivos que ocorreram menos de 10 vezes da lista. Eles poderiam voltar ao próximo teste e, se se encontrassem mais de 10 vezes, permaneceriam na lista. Talvez alguns resultados apresentem algum erro se algum nome comum raramente aparecer no primeiro lote de repositórios antes de se tornar comum. Em resumo, esses números não são absolutos, mas devem estar próximos o suficiente deles.Eu poderia usar a árvore de prefixos para "espremer" o espaço e obter os números absolutos, mas não queria escrevê-lo; portanto, abusei levemente do mapa para economizar memória e obter o resultado. No entanto, será bastante interessante tentar a árvore de prefixos posteriormente.Quantos repositórios estão faltando uma licença?
Isso é muito interessante. Quantos repositórios têm pelo menos algum arquivo de licença explícito? Observe que a ausência de um arquivo de licença aqui não significa que o projeto não o possui, pois ele pode existir no arquivo LEIA-ME ou pode ser indicado nas linhas de comentário do SPDX. Significa simplesmente que sccnão foi possível encontrar o arquivo de licença explícito usando seus próprios critérios. Atualmente, esses arquivos são considerados "licença", "licença", "cópia", "cópia3", "falta de licença", "falta de licença", "licença-mit", "licença-mit" ou "direitos autorais".Infelizmente, a grande maioria dos repositórios não possui uma licença. Eu diria que existem muitas razões pelas quais qualquer software precisa de uma licença, mas alguém disse isso para mim.
Quantos projetos usam vários arquivos .gitignore?
Alguns podem não saber disso, mas pode haver vários arquivos .gitignore em um projeto git. Com isso em mente, quantos projetos usam vários arquivos .gitignore? E, ao mesmo tempo, quantos não têm um único?Encontrei um projeto bastante interessante com 25.794 arquivos .gitignore no repositório. O próximo resultado foi 2547. Não tenho ideia do que está acontecendo lá. Olhei brevemente: parece que eles são usados para verificar diretórios, mas não posso confirmar isso.Voltando aos dados, aqui está um gráfico de repositórios com até 20 arquivos .gitignore, que cobrem 99% de todos os projetos.
Como esperado, a maioria dos projetos tem 0 ou 1 arquivos .gitignore. Isso é confirmado por uma queda maciça de dez vezes no número de projetos com arquivos 2. O que me surpreendeu foi quantos projetos possuem mais de um arquivo .gitignore. A cauda longa, neste caso, é especialmente longa.Fiquei curioso por que alguns projetos têm milhares desses arquivos. Um dos principais causadores de problemas é o fork https://github.com/PhantomX/slackbuilds : cada um deles possui cerca de 2547 arquivos .gitignore. Outros repositórios com mais de mil arquivos .gitignore estão listados abaixo.?
Esta seção não é uma ciência exata, mas pertence à classe de problemas do processamento de linguagem natural. A pesquisa de termos abusivos ou abusivos em uma lista específica de arquivos nunca será eficaz. Se você pesquisar com uma pesquisa simples, encontrará muitos arquivos comuns, como assemble.shetc. Então, peguei uma lista de maldições e verifiquei se algum arquivo em cada projeto começa com um desses valores seguido por um ponto. Isso significa que o arquivo nomeado gangbang.javaserá levado em consideração, mas assemble.shnão. No entanto, ele sentirá falta de muitas opções diferentes, como pu55syg4rgle.javaoutros nomes igualmente rudes.Minha lista contém algumas palavras no leetspeak, como b00bse b1tch, para capturar alguns dos casos interessantes. Lista completa aqui.Embora isso não seja totalmente preciso, como já mencionado, é incrivelmente interessante observar o resultado. Vamos começar com a lista de idiomas em que mais maldições. Provavelmente, você deve correlacionar o resultado com a quantidade total de código em cada idioma. Então, aqui estão os líderes.Interessante! Meu primeiro pensamento foi: “Oh, esses safados desenvolvedores C!” Mas, apesar do grande número desses arquivos, eles escrevem tanto código que a porcentagem de maldições é perdida no valor total. No entanto, é bastante claro que os desenvolvedores de Dart têm algumas palavras em seu arsenal! Se você conhece um dos programadores do Dart, pode apertar a mão dele.Também quero saber quais são as maldições mais usadas. Vejamos uma mente coletiva suja comum. Alguns dos melhores que encontrei foram nomes normais (se você olhar de soslaio), mas a maioria dos outros certamente surpreenderá os colegas e alguns comentários nos pedidos de pool.Observe que algumas das palavras mais ofensivas da lista tinham nomes de arquivos correspondentes, o que eu acho bastante chocante. Felizmente, eles não são muito comuns e não estão incluídos na lista acima, que é limitada a arquivos com um número superior a 100. Espero que esses arquivos existam apenas para testar listas de permissões / negações e similares.Os maiores arquivos pelo número de linhas em cada idioma
Como esperado, texto sem formatação, SQL, XML, JSON e CSV ocupam as primeiras posições: geralmente contêm metadados, despejos de banco de dados e similares.Nota Alguns dos links abaixo podem não funcionar devido a algumas informações adicionais ao criar arquivos. A maioria deve funcionar, mas para alguns, pode ser necessário modificar um pouco a URL.Qual é o arquivo mais complexo em todos os idiomas?
Mais uma vez, esses valores não são diretamente comparáveis entre si, mas é interessante ver o que é considerado o mais difícil em todos os idiomas.Alguns desses arquivos são monstros absolutos. Por exemplo, considere o arquivo C ++ mais complexo que encontrei: COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp : são 28,3 megabytes do inferno do compilador (e, felizmente, parece ser gerado automaticamente).Nota Alguns dos links abaixo podem não funcionar devido a algumas informações adicionais ao criar arquivos. A maioria deve funcionar, mas para alguns, pode ser necessário modificar um pouco a URL.O arquivo mais complicado sobre o número de linhas?
Parece bom em teoria, mas na realidade ... algo reduzido ou sem quebras de linha distorce os resultados, tornando-os sem sentido. Portanto, não publico os resultados dos cálculos. No entanto, criei um ticket para sccdar suporte à detecção de minificação, a fim de removê-lo dos resultados do cálculo.Você provavelmente pode tirar algumas conclusões com base nos dados disponíveis, mas quero que todos os usuários se beneficiem desse recurso scc.Qual é o arquivo mais comentado em cada idioma?
Não tenho idéia de quais informações valiosas você pode extrair disso, mas é interessante ver.Nota Alguns dos links abaixo podem não funcionar devido a algumas informações adicionais ao criar arquivos. A maioria deve funcionar, mas para alguns, pode ser necessário modificar um pouco a URL.Quantos projetos "limpos"
Sob o "puro", os tipos de projetos são puramente em um idioma. Obviamente, isso não é muito interessante por si só, então vamos vê-los em contexto. Como se viu, a grande maioria dos projetos tem menos de 25 idiomas e a maioria tem menos de dez.O pico no gráfico abaixo está em quatro idiomas.Obviamente, em projetos limpos, pode haver apenas uma linguagem de programação, mas há suporte para outros formatos, como markdown, json, yml, css, .gitignore, que são levados em consideração scc. Provavelmente, é razoável supor que qualquer projeto com menos de cinco idiomas seja "limpo" (para algum nível de limpeza), e isso representa pouco mais da metade do conjunto total de dados. Obviamente, sua definição de limpeza pode diferir da minha, para que você possa se concentrar em qualquer número que desejar.O que me surpreende é uma onda estranha em torno de 34-35 idiomas. Não tenho uma explicação razoável de onde veio, e isso provavelmente é digno de uma investigação separada.
Projetos com TypeScript, mas não JavaScript
Ah, o mundo moderno do TypeScript. Mas para projetos TypeScript, quantos são puramente nessa linguagem?Devo admitir que estou um pouco surpreso com esse número. Embora eu entenda que misturar JavaScript com TypeScript é bastante comum, acho que haveria mais projetos na linguagem newfangled. Mas é possível que um conjunto mais recente de repositórios aumente drasticamente seu número.Alguém usa CoffeeScript e TypeScript?
Sinto que alguns desenvolvedores de TypeScript ficam doentes só de pensar nisso. Se isso os ajudar, posso assumir que a maioria desses projetos são programas como sccexemplos de todos os idiomas para fins de teste.Qual é o tamanho típico do caminho em cada idioma
Como você pode fazer upload de todos os arquivos necessários em um diretório ou criar um sistema de diretórios, qual é o tamanho típico do caminho e o número de diretórios?Para fazer isso, conte o número de barras no caminho para cada arquivo e a média. Eu não sabia o que esperar aqui, exceto que o Java poderia estar no topo da lista, pois geralmente existem caminhos de arquivo longos.YAML ou YML?
Houve uma vez uma "discussão" no Slack - usando .yaml ou .yml. Muitos foram mortos lá dos dois lados.O debate pode finalmente terminar (?). Embora eu suspeite que alguns ainda prefiram morrer em uma disputa.Maiúsculas, minúsculas ou mistas?
Qual registro é usado para nomes de arquivos? Como ainda existe uma extensão, podemos esperar, principalmente, um caso misto.O que, é claro, não é muito interessante, porque geralmente as extensões de arquivo são minúsculas. E se ignorar extensões?Não é o que eu esperava. Mais uma vez, principalmente misturados, mas eu teria pensado que o fundo seria mais popular.Fábricas em Java
Outra idéia que os colegas tiveram quando analisaram algum código Java antigo. Pensei, por que não adicionar uma verificação para qualquer código Java onde Factory, FactoryFactory ou FactoryFactoryFactory apareça no título. A idéia é estimar o número dessas fábricas.Portanto, pouco mais de 2% do código Java acabou sendo uma fábrica ou fábrica. Felizmente, nenhuma fábrica foi encontrada. Talvez essa piada finalmente acabe, apesar de eu ter certeza de que pelo menos uma multifuncional recursiva séria de terceiro nível ainda funciona em algum tipo de monolito do Java 5 e ganha mais dinheiro todos os dias do que eu vi em toda a minha carreira. ..Ignore arquivos
A idéia de arquivos .ignore foi desenvolvida por burntsushi e ggreer em uma discussão no Hacker News . Talvez este seja um dos melhores exemplos de ferramentas de código aberto "concorrentes" que trabalham em conjunto com bons resultados e são concluídas em tempo recorde. Tornou-se o padrão de fato para adicionar código que as ferramentas ignoram. scctambém cumpre a regra .ignore, mas também sabe contá-las. Vamos ver o quão bem a idéia se espalhou.Ideias para o futuro
Eu gosto de fazer algumas análises para o futuro. Seria bom verificar coisas como as chaves do AWS AKIA e coisas do gênero. Eu também gostaria de expandir a cobertura dos projetos Bitbucket e Gitlab com análise para cada um, para ver se pode haver equipes de desenvolvimento de diferentes áreas por lá.Se eu repetir o projeto, gostaria de superar as seguintes deficiências e levar em conta as seguintes idéias.- Armazene URLs em algum lugar nos metadados corretamente. Usar um nome de arquivo para armazená-lo foi uma má idéia, pois as informações são perdidas e pode ser difícil determinar a origem e o local do arquivo.
- Não se preocupe com S3. Não faz sentido pagar pelo tráfego se eu o usar apenas para armazenamento. Desde o início, era melhor martelar tudo em um arquivo tar.
- , .
- -n , , , .
- scc, , . , CIDE.C C, , HTML. .
- , scc, , , . .
- Gostaria de adicionar uma detecção shebang ao scc .
- Seria bom considerar de alguma forma o número de estrelas no Github e o número de confirmações.
- Quero, de alguma forma, adicionar um cálculo de índice de manutenção. Seria muito bom ver quais projetos são considerados os mais reparáveis, dependendo do tamanho.
Por que isso é tudo?
Bem, eu posso pegar algumas dessas informações e usá-las no meu mecanismo de pesquisa e programa searchcode.com scc. Pelo menos alguns pontos de dados úteis. Inicialmente, o projeto foi concebido de várias maneiras para o efeito. Além disso, é muito útil comparar seu projeto com outros. Foi também uma maneira interessante de passar vários dias resolvendo alguns problemas interessantes. E uma boa verificação de confiabilidade scc.Além disso, atualmente estou trabalhando em uma ferramenta que ajuda os principais desenvolvedores ou gerentes a analisar o código, procurar idiomas específicos, arquivos grandes, falhas, etc. ... supondo que você precise analisar vários repositórios. Você digita algum tipo de código e a ferramenta diz como é sustentável e quais habilidades são necessárias para mantê-lo. Isso é útil ao decidir comprar algum tipo de base de código, fazer a manutenção ou obter uma idéia sobre o seu próprio produto que a equipe de desenvolvimento emite. Teoricamente, isso deve ajudar as equipes a escalar através de recursos compartilhados. Algo como o AWS Macie, mas para o código - algo como este no qual estou trabalhando. Eu mesmo preciso disso para o trabalho cotidiano e suspeito que outros possam encontrar aplicação para esse instrumento, pelo menos essa é a teoria.Talvez valha a pena colocar aqui alguma forma de registro para os interessados ...Arquivos não processados / processados
Se alguém quiser fazer sua própria análise e fazer correções, aqui está um link para os arquivos processados (20 MB). Se alguém quiser postar arquivos brutos em domínio público, informe-me. São tar.gz de 83 GB e o interior tem pouco mais de 1 TB. O conteúdo consiste em pouco mais de 9 milhões de arquivos JSON de vários tamanhos.UPD
Várias almas boas sugeriram colocar o arquivo, os locais são indicados abaixo:Hospedando este arquivo tar.gz, graças ao CNCF para o servidor para xet7 do projeto Wekan .