L'
outil de ligne de commande
Sloc Cloc and Code (scc) que j'ai écrit , qui est maintenant finalisé et pris en charge par de nombreuses personnes formidables, compte les lignes de code, les commentaires et évalue la complexité des fichiers dans un répertoire. Une bonne sélection est nécessaire ici. L'outil compte les opérateurs de branchement dans le code. Mais qu'est-ce que la complexité? Par exemple, l'énoncé «Ce fichier a une difficulté 10» n'est pas très utile sans contexte. Pour résoudre ce problème, j'ai exécuté
scc
sur toutes les sources sur Internet. Cela vous permettra également de trouver des cas extrêmes que je n'ai pas pris en compte dans l'outil lui-même. Test de force brute puissant.
Mais si je vais exécuter le test sur toutes les sources du monde, cela nécessitera beaucoup de ressources informatiques, ce qui est également une expérience intéressante. Par conséquent, j'ai décidé de tout écrire - et cet article est apparu.
En bref, j'ai téléchargé et traité de nombreuses sources.
Figures nues:
- 9 985 051 dépôts totaux
- 9 100 083 référentiels avec au moins un fichier
- 884968 référentiels vides (sans fichiers)
- 3 500 000 000 fichiers dans tous les référentiels
- Traités 40 736 530 379 778 octets (40 To)
- 1 086 723 618 560 rangées identifiées
- 816 822 273 469 lignes avec code reconnu
- 124 382 152 510 lignes blanches
- 145 519 192 581 lignes de commentaires
- Complexité totale selon les règles scc: 71 884 867 919
- 2 nouveaux bugs trouvés dans scc
Mentionnons juste un détail. Il n'y a pas 10 millions de projets, comme indiqué dans le titre très médiatisé. J'ai raté 15 000, alors je l'ai arrondi. Je m'en excuse.
Il a fallu environ cinq semaines pour tout télécharger, passer par scc et enregistrer toutes les données. Ensuite, un peu plus de 49 heures pour traiter 1 To JSON et obtenir les résultats ci-dessous.
Notez également que je peux me tromper dans certains calculs. Je vous informerai rapidement si une erreur est détectée et fournirai un ensemble de données.
Table des matières
Méthodologie
Depuis le lancement de
searchcode.com, j'ai déjà accumulé une collection de plus de 7 000 000 de projets sur git, mercurial, subversion et ainsi de suite. Alors pourquoi ne pas les traiter? Travailler avec git est généralement la solution la plus simple, donc cette fois j'ai ignoré mercurial et subversion et exporté une liste complète des projets git. Il s'avère que j'ai suivi 12 millions de dépôts git, et j'ai probablement besoin de rafraîchir la page principale pour refléter cela.
Alors maintenant, j'ai 12 millions de dépôts git à télécharger et à traiter.
Lorsque vous exécutez scc, vous pouvez sélectionner la sortie dans JSON en enregistrant le fichier sur le disque:
scc --format json --output myfile.json main.go
Les résultats sont les suivants (pour un seul fichier):
[ { "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 } ]
Pour un exemple plus grand, voir les résultats du projet
redis :
redis.json . Tous les résultats ci-dessous sont obtenus à partir d'un tel résultat sans aucune donnée supplémentaire.
Il convient de garder à l'esprit que scc classe généralement les langues en fonction de l'extension (sauf si l'extension est commune, comme Verilog et Coq). Ainsi, si vous enregistrez un fichier HTML avec l'extension java, il sera considéré comme un fichier java. Ce n'est généralement pas un problème, car pourquoi faire cela? Mais, bien sûr, à grande échelle, le problème devient perceptible. J'ai découvert cela plus tard lorsque certains fichiers ont été déguisés en une extension différente.
Il y a quelque temps, j'ai écrit du
code pour générer des balises github basées sur scc . Étant donné que le processus devait mettre en cache les résultats, je l'ai légèrement modifié pour les mettre en cache au format JSON sur AWS S3.
Avec le code des étiquettes dans AWS sur lambda, j'ai pris une liste exportée de projets, écrit environ 15 lignes python pour effacer le format pour correspondre à mon lambda, et lui ai fait une demande. En utilisant le multiprocessing python, j'ai parallélisé les requêtes à 32 processus afin que le point de terminaison réponde assez rapidement.
Tout fonctionnait parfaitement. Cependant, le problème était, d'une part, en termes de coût, et d'autre part, lambda a un délai d'expiration de 30 secondes pour API Gateway / ALB, de sorte qu'il ne peut pas traiter les grands référentiels assez rapidement. Je savais que ce n'était pas la solution la plus économique, mais je pensais que le prix serait d'environ 100 $, ce que je supporterais. Après avoir traité un million de référentiels, j'ai vérifié - et le coût était d'environ 60 $. Comme je n'étais pas satisfait de la perspective d'un compte AWS final de 700 $, j'ai décidé de reconsidérer ma décision. Gardez à l'esprit qu'il s'agissait essentiellement du stockage et du processeur utilisés pour collecter toutes ces informations. Tout traitement et exportation de données a considérablement augmenté le prix.
Comme j'étais déjà sur AWS, une solution rapide serait de supprimer les URL en tant que messages dans SQS et de les retirer en utilisant des instances EC2 ou Fargate pour le traitement. Puis évoluez comme un fou. Mais malgré l'expérience quotidienne avec AWS, j'ai toujours cru aux
principes de la programmation de Taco Bell . De plus, il n'y avait que 12 millions de référentiels, j'ai donc décidé de mettre en œuvre une solution plus simple (moins chère).
Il n'a pas été possible de commencer le calcul localement en raison du terrible Internet en Australie. Cependant, mon searchcode.com fonctionne en utilisant les serveurs dédiés de Hetzner avec soin. Ce sont des machines i7 Quad Core 32 Go de RAM assez puissantes, souvent avec 2 To d'espace de stockage (généralement non utilisés). Ils disposent généralement d'une bonne puissance de calcul. Par exemple, le serveur frontal calcule la plupart du temps la racine carrée de zéro. Alors pourquoi ne pas commencer le traitement là-bas?
Ce n'est pas vraiment de la programmation Taco Bell puisque j'ai utilisé les outils bash et gnu. J'ai écrit un
programme simple sur Go pour exécuter 32 go-routines qui lisent les données d'un canal, génèrent des sous-processus git et scc avant d'écrire la sortie sur JSON en S3. En fait, j'ai écrit la solution en premier en Python, mais la nécessité d'installer des dépendances pip sur mon serveur propre semblait être une mauvaise idée, et le système s'est écrasé de manière étrange que je ne voulais pas déboguer.
L'exécution de tout cela sur le serveur a produit les métriques suivantes dans htop, et plusieurs processus git / scc en cours d'exécution (scc n'apparaît pas dans cette capture d'écran) ont supposé que tout fonctionnait comme prévu, ce qui a été confirmé par les résultats dans S3.

Présentation et calcul des résultats
J'ai récemment lu
ces articles , j'ai donc eu l'idée d'emprunter le format de ces articles en relation avec la présentation des informations. Cependant, je voulais également ajouter
jQuery DataTables à de grands tableaux pour trier et rechercher / filtrer les résultats. Ainsi, dans l'
article d'origine, vous pouvez cliquer sur les titres pour trier et utiliser le champ de recherche pour filtrer.
La taille des données à traiter a soulevé une autre question. Comment traiter 10 millions de fichiers JSON, occupant un peu plus de 1 To d'espace disque dans le compartiment S3?
La première pensée a été AWS Athena. Mais comme cela coûterait quelque chose comme 2,50 $
par requête pour un tel ensemble de données, j'ai rapidement commencé à chercher une alternative. Cependant, si vous enregistrez les données là-bas et les traitez rarement, cela peut être la solution la moins chère.
J'ai posté une question dans le chat d'entreprise (pourquoi résoudre des problèmes seul).
Une idée était de vider les données dans une grande base de données SQL. Cependant, cela signifie traiter les données dans la base de données, puis exécuter plusieurs fois des requêtes sur celle-ci. De plus, la structure de données signifie plusieurs tables, ce qui signifie des clés étrangères et des index pour fournir un certain niveau de performance. Cela semble inutile, car nous pourrions simplement traiter les données pendant que nous les lisons sur le disque - en une seule fois. J'étais également inquiet de créer une base de données aussi grande. Avec des données uniquement, sa taille sera supérieure à 1 To avant d'ajouter des index.
Voyant comment j'ai créé JSON d'une manière simple, j'ai pensé, pourquoi ne pas traiter les résultats de la même manière? Bien sûr, il y a un problème. Extraire 1 To de données de S3 coûtera cher. Si le programme plante, ce sera ennuyeux. Pour réduire les coûts, je voulais retirer tous les fichiers localement et les enregistrer pour un traitement ultérieur. Bon conseil: il vaut mieux ne pas stocker de
nombreux petits fichiers dans un seul répertoire . Cela craint pour les performances d'exécution, et les systèmes de fichiers n'aiment pas cela.
Ma réponse à cela était un autre
programme Go simple pour extraire des fichiers de S3, puis les enregistrer dans un fichier tar. Ensuite, je pourrais traiter ce fichier encore et encore. Le processus lui-même exécute un
programme Go très laid pour traiter le fichier tar afin que je puisse réexécuter les requêtes sans avoir à extraire les données de S3 encore et encore. Je n'ai pas pris la peine de faire des routines ici pour deux raisons. Tout d'abord, je ne voulais pas charger le serveur autant que possible, donc je me suis limité à un cœur pour que le CPU travaille dur (l'autre était principalement verrouillé sur le processeur pour lire le fichier tar). Deuxièmement, je voulais garantir la sécurité des fils.
Une fois cela fait, une série de questions était nécessaire pour répondre. J'ai à nouveau utilisé l'esprit collectif et connecté mes collègues pendant que je proposais mes propres idées. Le résultat de cette fusion des esprits est présenté ci-dessous.
Vous pouvez trouver
tout le code que j'ai utilisé pour traiter JSON, y compris le code pour le traitement local et le
vilain script Python que j'ai utilisé pour préparer quelque chose d'utile pour cet article: veuillez ne pas commenter, je sais que le code est moche , et il est écrit pour une tâche ponctuelle, car il est peu probable que je le revoie jamais.
Si vous voulez voir le code que j'ai écrit pour une utilisation générale, regardez les
sources scc .
Coût
J'ai dépensé environ 60 $ en informatique en essayant de travailler avec lambda. Je n'ai pas encore examiné le coût de stockage de S3, mais il devrait être proche de 25 $, selon la taille des données. Cependant, cela n'inclut pas les coûts de transmission, que je n'ai pas surveillés non plus. Veuillez noter que j'ai nettoyé le seau lorsque j'en ai fini, donc ce n'est pas un coût fixe.
Mais après un certain temps, j'ai encore abandonné AWS. Alors, quel est le coût réel si je voulais recommencer?
Tous les logiciels que nous avons sont gratuits et gratuits. Il n'y a donc rien à craindre.
Dans mon cas, le coût serait nul, puisque j'ai utilisé la puissance de calcul «gratuite» de searchcode.com. Cependant, tout le monde n'a pas de telles ressources gratuites. Par conséquent, supposons que l'autre personne veuille répéter cela et doit relever le serveur.
Cela peut être fait pour 73 € en utilisant le nouveau
serveur dédié le moins cher
de Hetzner , y compris le coût d'installation d'un nouveau serveur. Si vous attendez et explorez la
section des enchères , vous pouvez trouver des serveurs beaucoup moins chers sans frais d'installation. Au moment d'écrire ces lignes, j'ai trouvé une voiture parfaite pour ce projet, pour 25,21 € par mois sans frais d'installation.

Ce qui est encore mieux, en dehors de l'Union européenne, la TVA sera supprimée de ce prix, alors n'hésitez pas à prendre encore 10%.
Par conséquent, si vous supprimez un tel service à partir de zéro sur mon logiciel, cela coûtera finalement jusqu'à 100 $, mais plutôt jusqu'à 50 $, si vous êtes un peu patient ou que vous réussissez. Cela suppose que vous utilisez le serveur depuis moins de deux mois, ce qui est suffisant pour le téléchargement et le traitement. Il y a également suffisamment de temps pour obtenir une liste de 10 millions de référentiels.
Si j'ai utilisé un tar compressé (ce qui n'est pas si difficile en fait), je pourrais traiter 10 fois plus de référentiels sur la même machine, et le fichier résultant restera toujours assez petit pour tenir sur le même disque dur. Bien que le processus puisse prendre plusieurs mois, car le téléchargement prendra plus de temps.
Cependant, pour aller bien au-delà des 100 millions de référentiels, une sorte de partage est nécessaire. Néanmoins, il est sûr de dire que vous répéterez le processus sur ma balance ou beaucoup plus grande, sur le même équipement sans trop d'effort ou de changements de code.
Sources de données
Voici le nombre de projets provenant de chacune des trois sources: github, bitbucket et gitlab. Notez que ceci est avant d'exclure les référentiels vides, par conséquent, le montant dépasse le nombre de référentiels qui sont réellement traités et pris en compte dans les tableaux suivants.
Je m'excuse auprès du personnel de GitHub / Bitbucket / GitLab si vous lisez ceci. Si mon script a causé des problèmes (bien que j'en doute), j'ai un verre de votre choix lors de ma rencontre.
Combien de fichiers se trouvent dans le référentiel?
Passons aux vrais problèmes. Commençons par un simple. Combien de fichiers se trouvent dans le référentiel moyen? La plupart des projets n'ont que quelques fichiers ou plus? Après avoir parcouru les référentiels, nous obtenons le calendrier suivant:

Ici, l'axe des x montre les compartiments avec le nombre de fichiers, et l'axe des y montre le nombre de projets avec autant de fichiers. Limitez l'axe horizontal à mille fichiers, car le graphique est alors trop proche de l'axe.
Il semble que la plupart des référentiels contiennent moins de 200 fichiers.
Mais qu'en est-il de la visualisation jusqu'au 95e centile, qui montrera l'image réelle? Il s'avère que dans la grande majorité (95%) des projets - moins de 1000 fichiers. Alors que 90% des projets ont moins de 300 fichiers et 85% en ont moins de 200.

Si vous voulez construire un graphique vous-même et le faire mieux que moi, voici un
lien vers les données brutes en JSON .
Quelle est la répartition linguistique?
Par exemple, si un fichier Java est identifié, alors nous augmentons le nombre de Java dans les projets d'un, et nous ne faisons rien pour le deuxième fichier. Cela donne une idée rapide des langues les plus couramment utilisées. Sans surprise, les langages les plus courants sont le markdown, le .gitignore et le texte en clair.
Markdown est le langage le plus utilisé; il est utilisé dans plus de 6 millions de projets, ce qui représente environ les 2/3 du total. Cela a du sens, car presque tous les projets incluent README.md qui est affiché en HTML pour les pages du référentiel.
Combien de fichiers sont dans le référentiel par langue?
Ajout au tableau précédent, mais en moyenne par le nombre de fichiers pour chaque langue dans le référentiel. Autrement dit, combien de fichiers Java existent en moyenne pour tous les projets où il y a Java?
Combien de lignes de code dans un fichier de langue typique?
Je suppose qu'il est toujours intéressant de voir quelles langues ont les fichiers les plus volumineux en moyenne? L'utilisation de la moyenne arithmétique génère des nombres anormalement élevés en raison de projets comme sqlite.c, qui est inclus dans de nombreux référentiels, combinant de nombreux fichiers en un seul, mais personne ne travaille jamais sur ce seul gros fichier (j'espère!)Par conséquent, j'ai calculé la moyenne de la médiane. Cependant, les langues avec des valeurs absurdement élevées, comme Bosque et JavaScript, sont restées.Alors j'ai pensé, pourquoi ne pas faire le pas d'un chevalier? À la suggestion de Darrell (un résident de Kablamo et un excellent scientifique des données), j'ai apporté un petit changement et changé la moyenne arithmétique, en supprimant des fichiers de plus de 5 000 lignes pour supprimer les anomalies.Complexité moyenne des fichiers dans chaque langue?
Quelle est la complexité moyenne des fichiers pour chaque langue?En fait, les cotes de complexité ne peuvent pas être directement corrélées entre les langues. Extrait du fichier Lisezmoi lui scc
- même :Le score de complexité n'est qu'un nombre qui ne peut être mis en correspondance qu'entre des fichiers dans la même langue. Il ne doit pas être utilisé pour comparer directement les langues. La raison en est qu'il est calculé en recherchant des opérateurs de branche et de boucle pour chaque fichier.
Ainsi, les langages ne peuvent pas être comparés entre eux ici, bien que cela puisse être fait entre des langages similaires tels que Java et C, par exemple.Il s'agit d'une mesure plus précieuse pour les fichiers individuels dans la même langue. Ainsi, vous pouvez répondre à la question "Ce fichier avec lequel je travaille est-il plus facile ou plus difficile que la moyenne?"Je dois mentionner que je serai heureux des suggestions pour améliorer cette métrique dans scc . Pour une validation, il suffit généralement d'ajouter quelques mots-clés au fichier languages.json pour que tout programmeur puisse vous aider.Nombre moyen de commentaires pour les fichiers dans chaque langue?
Quel est le nombre moyen de commentaires dans les fichiers dans chaque langue?Peut-être que la question peut être reformulée: les développeurs dans quelle langue écrivent le plus de commentaires, suggérant une incompréhension du lecteur.Quels sont les noms de fichiers les plus courants?
Quels noms de fichiers sont les plus courants dans toutes les bases de code, en ignorant l'extension et la casse?Si vous me l'aviez demandé plus tôt, je dirais: README, main, index, license. Les résultats reflètent assez bien mes hypothèses. Bien qu'il y ait beaucoup de choses intéressantes. Je n'ai aucune idée pourquoi tant de projets contiennent un fichier appelé 15
ou s15
.Le makefile le plus courant m'a un peu surpris, mais je me suis alors souvenu qu'il était utilisé dans de nombreux nouveaux projets JavaScript. Une autre chose intéressante à noter: il semble que jQuery soit toujours sur le cheval, et les rapports de sa mort sont grandement exagérés, et il est à la quatrième place de la liste.Veuillez noter qu'en raison de limitations de mémoire, j'ai rendu ce processus un peu moins précis. Après 100 projets, j'ai vérifié la carte et supprimé les noms des fichiers apparus moins de 10 fois dans la liste. Ils pourraient revenir au test suivant, et s'ils se rencontraient plus de 10 fois, ils restaient sur la liste. Peut-être que certains des résultats contiennent une erreur si un nom commun apparaît rarement dans le premier lot de référentiels avant de devenir commun. En bref, ce ne sont pas des nombres absolus, mais devraient être assez proches d'eux.Je pouvais utiliser l’arbre des préfixes pour «presser» l’espace et obtenir les nombres absolus, mais je ne voulais pas l’écrire, alors j’ai légèrement abusé de la carte pour économiser suffisamment de mémoire et obtenir le résultat. Cependant, il sera très intéressant d'essayer plus tard l'arborescence des préfixes.Combien de référentiels n'ont pas de licence?
C'est très intéressant. Combien de référentiels ont au moins un fichier de licence explicite? Veuillez noter que l'absence d'un fichier de licence ici ne signifie pas que le projet ne l'a pas, car il peut exister dans le fichier README ou peut être indiqué via des balises de commentaire SPDX en lignes. Cela signifie simplement scc
qu'il n'a pas pu trouver le fichier de licence explicite en utilisant ses propres critères. Actuellement, ces fichiers sont considérés comme "licence", "licence", "copie", "copie3", "non-licence", "non-licence", "licence-mit", "licence-mit" ou "copyright".Malheureusement, la grande majorité des référentiels n'ont pas de licence. Je dirais qu'il existe de nombreuses raisons pour lesquelles un logiciel a besoin d'une licence, mais quelqu'un d'autre l'a dit pour moi.
Combien de projets utilisent plusieurs fichiers .gitignore?
Certains peuvent ne pas le savoir, mais il peut y avoir plusieurs fichiers .gitignore dans un projet git. Dans cet esprit, combien de projets utilisent plusieurs fichiers .gitignore? Et en même temps, combien n'en ont pas un seul?J'ai trouvé un projet assez intéressant avec 25 794 fichiers .gitignore dans le référentiel. Le résultat suivant était 2547. Je n'ai aucune idée de ce qui se passe là-bas. J’ai jeté un coup d’œil: on dirait qu’ils sont utilisés pour vérifier les répertoires, mais je ne peux pas le confirmer.Pour en revenir aux données, voici un graphique des référentiels contenant jusqu'à 20 fichiers .gitignore, qui couvre 99% de tous les projets.
Comme prévu, la plupart des projets ont 0 ou 1 fichier .gitignore. Cela est confirmé par une décuplée massive du nombre de projets avec 2 fichiers. Ce qui m'a surpris, c'est combien de projets ont plus d'un fichier .gitignore. La longue queue dans ce cas est particulièrement longue.J'étais curieux de savoir pourquoi certains projets ont des milliers de tels fichiers. L'un des principaux fauteurs de troubles est la fourchette https://github.com/PhantomX/slackbuilds : chacun d'eux a environ 2547 fichiers .gitignore. D'autres référentiels contenant plus d'un millier de fichiers .gitignore sont répertoriés ci-dessous.?
Cette section n'est pas une science exacte, mais appartient à la classe des problèmes de traitement du langage naturel. La recherche de termes abusifs ou abusifs dans une liste spécifique de fichiers ne sera jamais efficace. Si vous effectuez une recherche avec une recherche simple, vous trouverez de nombreux fichiers ordinaires comme assemble.sh
et ainsi de suite. J'ai donc pris une liste de malédictions, puis vérifié si des fichiers dans chaque projet commencent par l'une de ces valeurs suivie d'un point. Cela signifie que le fichier nommé gangbang.java
sera pris en compte, mais assemble.sh
pas. Cependant, il manquera de nombreuses options différentes, telles que d' pu55syg4rgle.java
autres noms tout aussi impolis.Ma liste contient quelques mots sur le leetspeak, comme b00bs
et b1tch
, pour attraper certains des cas intéressants. Liste complète ici.Bien que ce ne soit pas tout à fait exact, comme déjà mentionné, il est incroyablement intéressant de regarder le résultat. Commençons par la liste des langues dans lesquelles le plus de malédictions. Vous devriez probablement corréler le résultat avec la quantité totale de code dans chaque langue. Voici donc les dirigeants.Intéressant! Ma première pensée a été: "Oh, ces développeurs C coquins!" Mais malgré le grand nombre de ces fichiers, ils écrivent tellement de code que le pourcentage de malédictions est perdu dans le montant total. Cependant, il est assez clair que les développeurs de Dart ont quelques mots dans leur arsenal! Si vous connaissez l'un des programmeurs Dart, vous pouvez lui serrer la main.Je veux aussi savoir quelles sont les malédictions les plus utilisées. Regardons un sale esprit collectif commun. Certains des meilleurs que j'ai trouvés étaient des noms normaux (si vous plissez les yeux), mais la plupart des autres surprendront certainement vos collègues et certains commentaires dans les demandes de pool.Veuillez noter que certains des mots les plus offensants de la liste avaient des noms de fichiers correspondants, ce que je trouve assez choquant. Heureusement, ils ne sont pas très courants et ne sont pas inclus dans la liste ci-dessus, qui est limitée aux fichiers de plus de 100. J'espère que ces fichiers n'existent que pour tester les listes d'autorisation / refus et similaires.Les fichiers les plus volumineux par le nombre de lignes dans chaque langue
Comme prévu, le texte en clair, SQL, XML, JSON et CSV occupent les premières positions: ils contiennent généralement des métadonnées, des vidages de base de données, etc.Remarque Certains des liens ci-dessous peuvent ne pas fonctionner en raison d'informations supplémentaires lors de la création de fichiers. La plupart devraient fonctionner, mais pour certains, vous devrez peut-être modifier légèrement l'URL.Quel est le fichier le plus complexe dans toutes les langues?
Encore une fois, ces valeurs ne sont pas directement comparables entre elles, mais il est intéressant de voir ce qui est considéré comme le plus difficile dans chaque langue.Certains de ces fichiers sont des monstres absolus. Par exemple, considérons le fichier C ++ le plus complexe que j'ai trouvé: COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp : c'est 28,3 mégaoctets d'enfer du compilateur (et, heureusement, il semble être généré automatiquement).Remarque Certains des liens ci-dessous peuvent ne pas fonctionner en raison d'informations supplémentaires lors de la création de fichiers. La plupart devraient fonctionner, mais pour certains, vous devrez peut-être modifier légèrement l'URL.Le fichier le plus compliqué concernant le nombre de lignes?
Cela semble bon en théorie, mais en fait ... quelque chose de minifié ou sans coupure de ligne déforme les résultats, les rendant vides de sens. Par conséquent, je ne publie pas les résultats des calculs. Cependant, j'ai créé un ticket en scc
charge la détection de minification devait l' enlever à partir des résultats de calcul.Vous pouvez probablement tirer des conclusions sur la base des données disponibles, mais je souhaite que tous les utilisateurs bénéficient de cette fonctionnalité scc
.Quel est le fichier le plus commenté dans chaque langue?
Je n'ai aucune idée des informations précieuses que vous pouvez en tirer, mais c'est intéressant à voir.Remarque Certains des liens ci-dessous peuvent ne pas fonctionner en raison d'informations supplémentaires lors de la création de fichiers. La plupart devraient fonctionner, mais pour certains, vous devrez peut-être modifier légèrement l'URL.Combien de projets «propres»
Sous le "pur" dans les types de projets sont purement dans une seule langue. Bien sûr, ce n'est pas très intéressant en soi, alors regardons-les dans leur contexte. Il s'est avéré que la grande majorité des projets ont moins de 25 langues et la plupart en ont moins de dix.Le pic dans le graphique ci-dessous est en quatre langues.Bien sûr, dans les projets propres, il ne peut y avoir qu'un seul langage de programmation, mais il existe un support pour d'autres formats, tels que markdown, json, yml, css, .gitignore, qui sont pris en compte scc
. Il est probablement raisonnable de supposer que tout projet avec moins de cinq langues est «propre» (pour un certain niveau de propreté), et cela représente un peu plus de la moitié de l'ensemble de données total. Bien sûr, votre définition de la propreté peut différer de la mienne, vous pouvez donc vous concentrer sur n'importe quel nombre que vous aimez.Ce qui me surprend, c'est une étrange vague de 34 à 35 langues. Je n'ai aucune explication raisonnable d'où cela vient, et cela mérite probablement une enquête séparée.
Projets avec TypeScript mais pas JavaScript
Ah, le monde moderne de TypeScript. Mais pour les projets TypeScript, combien sont purement dans ce langage?Je dois admettre que je suis un peu surpris par ce chiffre. Bien que je comprenne que le mélange de JavaScript avec TypeScript est assez courant, je pense qu'il y aurait plus de projets dans le nouveau langage. Mais il est possible qu'un ensemble plus récent de référentiels augmente considérablement leur nombre.Quelqu'un utilise-t-il CoffeeScript et TypeScript?
J'ai l'impression que certains développeurs TypeScript sont malades à l'idée même de cela. Si cela les aide, je peux supposer que la plupart de ces projets sont des programmes comme scc
avec des exemples de toutes les langues à des fins de test.Quelle est la longueur typique du chemin dans chaque langue
Étant donné que vous pouvez soit télécharger tous les fichiers dont vous avez besoin dans un répertoire, soit créer un système de répertoires, quelle est la longueur de chemin et le nombre de répertoires typiques?Pour ce faire, comptez le nombre de barres obliques dans le chemin pour chaque fichier et la moyenne. Je ne savais pas à quoi m'attendre ici, sauf que Java pourrait être en haut de la liste, car il y a généralement de longs chemins de fichiers.YAML ou YML?
Il y a eu une fois une «discussion» à Slack - en utilisant .yaml ou .yml. Beaucoup y ont été tués des deux côtés.Le débat peut enfin (?) Se terminer. Bien que je soupçonne que certains préfèrent encore mourir dans un différend.Majuscules, minuscules ou casse mixte?
Quel registre est utilisé pour les noms de fichiers? Puisqu'il y a encore une extension, on peut s'attendre, principalement, à un cas mixte.Ce qui, bien sûr, n'est pas très intéressant, car généralement les extensions de fichier sont en minuscules. Et si ignorer les extensions?Pas ce à quoi je m'attendais. Encore une fois, principalement mixte, mais j'aurais pensé que le fond serait plus populaire.Usines à Java
Une autre idée que les collègues ont eue en regardant un vieux code Java. J'ai pensé, pourquoi ne pas ajouter une vérification pour tout code Java où Factory, FactoryFactory ou FactoryFactoryFactory apparaît dans le titre. L'idée est d'estimer le nombre de ces usines.Ainsi, un peu plus de 2% du code Java s'est avéré être une usine ou une usine. Heureusement, aucune usine d'usine n'a été trouvée. Peut-être que cette plaisanterie mourra enfin, même si je suis sûr qu'au moins une multifonctionnelle récursive sérieuse de troisième niveau fonctionne toujours quelque part dans une sorte de monolithe Java 5, et elle fait plus d'argent chaque jour que je n'en ai vu dans toute ma carrière. .Fichiers .gnore
L'idée des fichiers .ignore a été développée par burntsushi et ggreer dans une discussion sur Hacker News . C'est peut-être l'un des meilleurs exemples d'outils open source «concurrents» qui fonctionnent avec de bons résultats et sont réalisés en un temps record. C'est devenu la norme de facto pour ajouter du code que les outils ignoreront. scc
remplit également la règle .ignore, mais sait également les compter. Voyons voir comment l'idée s'est propagée.Des idées pour l'avenir
J'aime faire une analyse pour l'avenir. Ce serait bien de scanner des choses comme les clés AWS AKIA et autres. Je voudrais également étendre la couverture des projets Bitbucket et Gitlab avec une analyse pour chacun, pour voir s'il peut y avoir des équipes de développement de différents domaines.Si jamais je répète le projet, je voudrais surmonter les lacunes suivantes et prendre en compte les idées suivantes.- Stockez correctement les URL quelque part dans les métadonnées. L'utilisation d'un nom de fichier pour le stocker était une mauvaise idée, car les informations sont perdues et il peut être difficile de déterminer la source et l'emplacement du fichier.
- Ne vous embêtez pas avec S3. Cela n'a pas de sens de payer pour le trafic si je ne l'utilise que pour le stockage. Il valait mieux dès le début de tout marteler dans un fichier tar.
- , .
- -n , , , .
- scc, , . , CIDE.C C, , HTML. .
- , scc, , , . .
- Je voudrais ajouter une détection de shebang à scc .
- Ce serait bien de considérer le nombre d'étoiles sur Github et le nombre de commits.
- Je veux en quelque sorte ajouter un calcul d'indice de maintenabilité. Il serait très agréable de voir quels projets sont considérés comme les plus réparables en fonction de leur taille.
Pourquoi tout cela?
Eh bien, je peux prendre certaines de ces informations et les utiliser dans mon moteur et programme de recherche searchcode.com scc
. Au moins quelques points de données utiles. Initialement, le projet a été conçu de plusieurs façons pour cela. De plus, il est très utile de comparer votre projet avec d'autres. C'était aussi une façon intéressante de passer plusieurs jours à résoudre des problèmes intéressants. Et une bonne vérification de fiabilité scc
.De plus, je travaille actuellement sur un outil qui aide les principaux développeurs ou gestionnaires à analyser du code, à rechercher des langues spécifiques, des fichiers volumineux, des failles, etc. ... en supposant que vous devez analyser plusieurs référentiels. Vous entrez une sorte de code et l'outil indique à quel point il est maintenable et quelles compétences sont nécessaires pour le maintenir. Cela est utile pour décider d'acheter une sorte de base de code, de la réparer ou de se faire une idée de votre propre produit que l'équipe de développement distribue. Théoriquement, cela devrait aider les équipes à évoluer grâce à des ressources partagées. Quelque chose comme AWS Macie, mais pour le code - quelque chose comme ça, je travaille. J'ai moi-même besoin de cela pour le travail quotidien, et je soupçonne que d'autres peuvent trouver une application pour un tel instrument, du moins c'est la théorie.Il vaudrait peut-être la peine de mettre ici une forme d'enregistrement pour les personnes intéressées ...Fichiers non traités / traités
Si quelqu'un veut faire sa propre analyse et faire des corrections, voici un lien vers les fichiers traités (20 Mo). Si quelqu'un veut publier des fichiers bruts dans le domaine public, faites le moi savoir. Il s'agit de 83 Go tar.gz, et à l'intérieur d'un peu plus de 1 To. Le contenu se compose d'un peu plus de 9 millions de fichiers JSON de différentes tailles.UPD
Plusieurs bonnes âmes ont suggéré de placer le dossier, les lieux sont indiqués ci-dessous:En hébergeant ce fichier tar.gz, merci à CNCF pour le serveur pour xet7 du projet Wekan .