La
herramienta de línea de comando
Sloc Cloc and Code (scc) que escribí , que ahora está finalizada y respaldada por muchas personas excelentes, cuenta líneas de código, comenta y evalúa la complejidad de los archivos dentro de un directorio. Se necesita una buena selección aquí. La herramienta cuenta los operadores de ramificación en código. ¿Pero qué es la complejidad? Por ejemplo, la declaración "Este archivo tiene dificultad 10" no es muy útil sin contexto. Para resolver este problema, ejecuté
scc en todas las fuentes en Internet. Esto también le permitirá encontrar algunos casos extremos que no consideré en la herramienta misma. Potente prueba de fuerza bruta.
Pero si voy a ejecutar la prueba en todas las fuentes del mundo, requerirá muchos recursos informáticos, lo que también es una experiencia interesante. Por lo tanto, decidí escribir todo, y apareció este artículo.
En resumen, descargué y procesé muchas fuentes.
Figuras desnudas:
- 9,985,051 repositorios totales
- 9.100.083 repositorios con al menos un archivo
- 884 968 repositorios vacíos (sin archivos)
- 3,500,000,000 archivos en todos los repositorios
- Procesado 40736530379778 bytes (40 TB)
- 1,086,723,618,560 filas identificadas
- 816,822,273,469 líneas con código reconocido
- 124 382 152 510 líneas en blanco
- 145 519 192 581 líneas de comentarios
- Complejidad total según las normas scc: 718844867919
- 2 nuevos errores encontrados en scc
Solo mencionemos un detalle. No hay 10 millones de proyectos, como se indica en el título de alto perfil. Perdí 15,000, así que lo redondeé. Pido disculpas por esto.
Tomó alrededor de cinco semanas descargar todo, pasar por scc y guardar todos los datos. Luego, un poco más de 49 horas para procesar 1 TB JSON y obtener los resultados a continuación.
También tenga en cuenta que podría estar equivocado en algunos cálculos. Le informaré de inmediato si se detecta algún error y le proporcionaré un conjunto de datos.
Tabla de contenidos
Metodología
Desde el lanzamiento de
searchcode.com, ya he acumulado una colección de más de 7,000,000 de proyectos en git, mercurial, subversión, etc. Entonces, ¿por qué no procesarlos? Trabajar con git suele ser la solución más fácil, por lo que esta vez ignoré mercurial y subversion y exporté una lista completa de proyectos de git. Resulta que en realidad rastreé 12 millones de repositorios git, y probablemente necesito actualizar la página principal para reflejar esto.
Entonces ahora tengo 12 millones de repositorios git para descargar y procesar.
Cuando ejecuta scc, puede seleccionar la salida en JSON guardando el archivo en el disco:
scc --format json --output myfile.json main.go Los resultados son los siguientes (para un solo archivo):
[ { "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 un ejemplo más amplio, vea los resultados del proyecto
redis :
redis.json . Todos los resultados a continuación se obtienen de dicho resultado sin ningún dato adicional.
Debe tenerse en cuenta que scc generalmente clasifica los idiomas en función de la extensión (a menos que la extensión sea común, como Verilog y Coq). Por lo tanto, si guarda un archivo HTML con la extensión java, se considerará un archivo java. Esto generalmente no es un problema, porque ¿por qué hacer esto? Pero, por supuesto, a gran escala, el problema se vuelve notable. Descubrí esto más tarde cuando algunos archivos se disfrazaron como una extensión diferente.
Hace algún tiempo escribí un
código para generar etiquetas github basadas en scc . Como el proceso necesitaba almacenar en caché los resultados, lo cambié un poco para almacenarlos en formato JSON en AWS S3.
Con el código para etiquetas en AWS en lambda, tomé una lista exportada de proyectos, escribí unas 15 líneas de python para borrar el formato para que coincida con mi lambda, y le hice una solicitud. Usando el multiprocesamiento de Python, paralelicé las solicitudes a 32 procesos para que el punto final respondiera lo suficientemente rápido.
Todo funcionó brillantemente. Sin embargo, el problema era, en primer lugar, el costo y, en segundo lugar, lambda tiene un tiempo de espera de 30 segundos para API Gateway / ALB, por lo que no puede procesar repositorios grandes con la suficiente rapidez. Sabía que esta no era la solución más económica, pero pensé que el precio sería de alrededor de $ 100, lo que soportaría. Después de procesar un millón de repositorios, lo comprobé, y el costo fue de aproximadamente $ 60. Como no estaba contento con la perspectiva de una cuenta final de AWS de $ 700, decidí reconsiderar mi decisión. Tenga en cuenta que este fue básicamente el almacenamiento y la CPU que se utilizaron para recopilar toda esta información. Cualquier procesamiento y exportación de datos aumentó significativamente el precio.
Como ya estaba en AWS, una solución rápida sería volcar las URL como mensajes en SQS y extraerlas utilizando instancias de EC2 o Fargate para su procesamiento. Luego escala como loco. Pero a pesar de la experiencia cotidiana con AWS, siempre he creído en los
principios de la programación de Taco Bell . Además, solo había 12 millones de repositorios, así que decidí implementar una solución más simple (más barata).
Comenzar el cálculo localmente no fue posible debido a la terrible Internet en Australia. Sin embargo, mi searchcode.com funciona utilizando los servidores dedicados de Hetzner con cuidado. Estas son máquinas i7 Quad Core 32 GB RAM bastante potentes, a menudo con 2 TB de espacio de almacenamiento (generalmente no se usan). Suelen tener un buen suministro de potencia informática. Por ejemplo, el servidor front-end la mayoría de las veces calcula la raíz cuadrada de cero. Entonces, ¿por qué no comenzar a procesar allí?
Esto no es realmente la programación de Taco Bell ya que usé las herramientas bash y gnu. Escribí un
programa simple en Go para ejecutar 32 rutinas go que leen datos de un canal, generan subprocesos git y scc antes de escribir la salida en JSON en S3. En realidad, escribí la solución primero en Python, pero la necesidad de instalar dependencias de pip en mi servidor limpio parecía una mala idea, y el sistema se bloqueó de formas extrañas que no quería depurar.
La ejecución de todo esto en el servidor produjo las siguientes métricas en htop, y varios procesos en ejecución de git / scc (scc no aparece en esta captura de pantalla) asumieron que todo estaba funcionando como se esperaba, lo que fue confirmado por los resultados en S3.
Presentación y cálculo de resultados.
Recientemente leí
estos artículos , así que tuve la idea de tomar prestado el formato de estas publicaciones en relación con la presentación de información. Sin embargo, también quería agregar
jQuery DataTables a tablas grandes para ordenar y buscar / filtrar los resultados. Por lo tanto, en el
artículo original, puede hacer clic en los encabezados para ordenar y usar el campo de búsqueda para filtrar.
El tamaño de los datos que debían procesarse planteó otra pregunta. ¿Cómo procesar 10 millones de archivos JSON, ocupando un poco más de 1 TB de espacio en disco en el bucket S3?
El primer pensamiento fue AWS Athena. Pero como costaría algo así como $ 2.50
por consulta para tal conjunto de datos, rápidamente comencé a buscar una alternativa. Sin embargo, si guarda los datos allí y rara vez los procesa, esta puede ser la solución más barata.
Publiqué una pregunta en el chat corporativo (por qué resolver problemas solo).
Una idea era volcar datos en una gran base de datos SQL. Sin embargo, esto significa procesar los datos en la base de datos y luego ejecutar consultas varias veces. Además, la estructura de datos significa varias tablas, lo que significa claves e índices foráneos para proporcionar un cierto nivel de rendimiento. Esto parece un desperdicio, porque podríamos procesar los datos a medida que los leemos del disco, de una sola vez. También me preocupaba crear una base de datos tan grande. Solo con datos, tendrá un tamaño de más de 1 TB antes de agregar índices.
Al ver cómo creé JSON de una manera simple, pensé, ¿por qué no procesar los resultados de la misma manera? Por supuesto, hay un problema. Extraer 1 TB de datos de S3 costará mucho. Si el programa falla, será molesto. Para reducir los costos, quería extraer todos los archivos localmente y guardarlos para su posterior procesamiento. Un buen consejo: es mejor no almacenar
muchos archivos pequeños en un directorio . Esto apesta al rendimiento en tiempo de ejecución, y a los sistemas de archivos no les gusta eso.
Mi respuesta a esto fue otro simple
programa Go para extraer archivos de S3 y luego guardarlos en un archivo tar. Entonces podría procesar este archivo una y otra vez. El proceso en sí ejecuta un
programa Go muy feo para procesar el archivo tar para que pueda volver a ejecutar las consultas sin tener que extraer datos de S3 una y otra vez. No me molesté con las rutinas de go aquí por dos razones. En primer lugar, no quería cargar el servidor tanto como fuera posible, así que me limité a un núcleo para que la CPU trabaje duro (el otro estaba bloqueado principalmente en el procesador para leer el archivo tar). En segundo lugar, quería garantizar la seguridad del hilo.
Cuando esto se hizo, se necesitaba un conjunto de preguntas para responder. Nuevamente utilicé la mente colectiva y conecté a mis colegas mientras se me ocurrían mis propias ideas. El resultado de esta fusión de mentes se presenta a continuación.
Puede encontrar
todo el código que utilicé para procesar JSON, incluido el código para el procesamiento local, y el
script de Python feo que utilicé para preparar algo útil para este artículo: por favor no lo comente, sé que el código es feo , y está escrito para una tarea única, ya que es poco probable que lo vuelva a ver.
Si quieres ver el código que escribí para uso general, mira las
fuentes scc .
Costo
Gasté alrededor de $ 60 en informática mientras intentaba trabajar con lambda. Todavía no he analizado el costo de almacenar S3, pero debería estar cerca de $ 25, dependiendo del tamaño de los datos. Sin embargo, esto no incluye los costos de transmisión, que tampoco vi. Tenga en cuenta que limpié el cubo cuando terminé con él, por lo que este no es un costo fijo.
Pero después de un tiempo todavía abandoné AWS. Entonces, ¿cuál es el costo real si quisiera volver a hacerlo?
Todo el software que tenemos es gratuito y gratuito. Entonces no hay nada de qué preocuparse.
En mi caso, el costo sería cero, ya que utilicé la potencia informática "gratuita" que quedaba de searchcode.com. Sin embargo, no todos tienen esos recursos gratuitos. Por lo tanto, supongamos que la otra persona quiere repetir esto y debe elevar el servidor.
Esto se puede hacer por 73 € utilizando el nuevo
servidor dedicado más barato
de Hetzner , incluido el costo de instalar un nuevo servidor. Si espera y profundiza en la
sección de subastas , puede encontrar servidores mucho más baratos sin tarifas de instalación. Al momento de escribir, encontré un automóvil que es perfecto para este proyecto, por € 25.21 al mes sin tarifas de instalación.
Lo que es aún mejor, fuera de la Unión Europea, el IVA se eliminará de este precio, así que no dude en tomar otro 10%.
Por lo tanto, si levanta un servicio de este tipo desde cero en mi software, en última instancia le costará hasta $ 100, pero más bien hasta $ 50, si es un poco paciente o exitoso. Esto supone que ha estado utilizando el servidor durante menos de dos meses, lo cual es suficiente para descargar y procesar. También hay tiempo suficiente para obtener una lista de 10 millones de repositorios.
Si usara un alquitrán comprimido (que en realidad no es tan difícil), podría procesar 10 veces más repositorios en la misma máquina, y el archivo resultante seguirá siendo lo suficientemente pequeño como para caber en el mismo HDD. Aunque el proceso puede llevar varios meses, porque la descarga llevará más tiempo.
Sin embargo, para ir más allá de los 100 millones de repositorios, se requiere algún tipo de fragmentación. Sin embargo, es seguro decir que repetirá el proceso en mi escala o mucho más, en el mismo equipo sin mucho esfuerzo o cambios de código.
Fuentes de datos
He aquí cuántos proyectos provienen de cada una de las tres fuentes: github, bitbucket y gitlab. Tenga en cuenta que esto es antes de excluir los repositorios vacíos, por lo tanto, la cantidad excede el número de repositorios que realmente se procesan y se tienen en cuenta en las siguientes tablas.
Pido disculpas al personal de GitHub / Bitbucket / GitLab si lees esto. Si mi guión causó algún problema (aunque lo dudo), tengo un trago de su elección al conocerme.
¿Cuántos archivos hay en el repositorio?
Pasemos a los problemas reales. Comencemos con uno simple. ¿Cuántos archivos hay en el repositorio promedio? ¿La mayoría de los proyectos solo tienen un par de archivos o más? Después de recorrer los repositorios, obtenemos el siguiente programa:
Aquí, el eje x muestra depósitos con la cantidad de archivos, y el eje y muestra la cantidad de proyectos con tantos archivos. Limite el eje horizontal a mil archivos, porque entonces el gráfico está demasiado cerca del eje.
Parece que la mayoría de los repositorios tienen menos de 200 archivos.
Pero, ¿qué pasa con la visualización hasta el percentil 95, que mostrará la imagen real? Resulta que en la gran mayoría (95%) de los proyectos, menos de 1000 archivos. Mientras que el 90% de los proyectos tienen menos de 300 archivos y el 85% tienen menos de 200.
Si desea crear un gráfico usted mismo y hacerlo mejor que yo, aquí hay un
enlace a los datos sin procesar en JSON .
¿Cuál es el desglose del idioma?
Por ejemplo, si se identifica un archivo Java, entonces aumentamos el número de Java en los proyectos en uno, y no hacemos nada para el segundo archivo. Esto da una idea rápida de qué idiomas se usan más comúnmente. Como era de esperar, los lenguajes más comunes incluyen markdown, .gitignore y texto sin formato.
Markdown es el lenguaje más utilizado; se ve en más de 6 millones de proyectos, que es aproximadamente 2⁄3 del total. Esto tiene sentido, ya que casi todos los proyectos incluyen README.md que se muestra en HTML para páginas de repositorio.
¿Cuántos archivos hay en el repositorio por idioma?
Adición a la tabla anterior, pero promediada por el número de archivos para cada idioma en el repositorio. Es decir, ¿cuántos archivos Java existen en promedio para todos los proyectos donde hay Java?
¿Cuántas líneas de código hay en un archivo de idioma típico?
¿Creo que todavía es interesante ver qué idiomas tienen los archivos más grandes en promedio? El uso de la media aritmética genera números anormalmente altos debido a proyectos como sqlite.c, que se incluye en muchos repositorios, combinando muchos archivos en uno, pero nadie trabaja en este archivo grande (¡espero!)Por lo tanto, calculé el promedio de la mediana. Sin embargo, los lenguajes con valores absurdamente altos, como Bosque y JavaScript, aún permanecen.Entonces pensé, ¿por qué no hacer el movimiento de un caballero? A sugerencia de Darrell (un residente de Kablamo y un excelente científico de datos), hice un pequeño cambio y cambié la media aritmética, colocando archivos en más de 5,000 líneas para eliminar anomalías.¿Complejidad de archivo promedio en cada idioma?
¿Cuál es la complejidad promedio de los archivos para cada idioma?De hecho, las clasificaciones de complejidad no pueden correlacionarse directamente entre idiomas. Extracto del propio archivo Léame scc:El puntaje de complejidad es solo un número que solo puede coincidir entre archivos en el mismo idioma. No debe usarse para comparar idiomas directamente. La razón es que se calcula buscando operadores de rama y bucle para cada archivo.
Por lo tanto, los lenguajes no se pueden comparar entre sí aquí, aunque esto se puede hacer entre lenguajes similares como Java y C, por ejemplo.Esta es una métrica más valiosa para archivos individuales en el mismo idioma. Por lo tanto, puede responder la pregunta "¿Este archivo con el que estoy trabajando es más fácil o más difícil que el promedio?"Debo mencionar que estaré contento con sugerencias para mejorar esta métrica en scc . Para una confirmación, generalmente es suficiente agregar solo algunas palabras clave al archivo languages.json, para que cualquier programador pueda ayudar.¿Número promedio de comentarios para archivos en cada idioma?
¿Cuál es el número promedio de comentarios en archivos en cada idioma?Quizás la pregunta pueda reformularse: los desarrolladores en qué idioma escriben la mayoría de los comentarios, lo que sugiere un malentendido del lector.¿Cuáles son los nombres de archivo más comunes?
¿Qué nombres de archivo son más comunes en todas las bases de código, ignorando la extensión y el caso?Si me preguntaras antes, diría: LÉAME, principal, índice, licencia. Los resultados reflejan bastante bien mis suposiciones. Aunque hay muchas cosas interesantes. No tengo idea de por qué tantos proyectos contienen un archivo llamado 15o s15.El archivo MAKE más común me sorprendió un poco, pero luego recordé que se utilizó en muchos proyectos nuevos de JavaScript. Otra cosa interesante a tener en cuenta: parece que jQuery todavía está en el caballo, y los informes de su muerte son muy exagerados, y él está en el cuarto lugar en la lista.Tenga en cuenta que debido a las limitaciones de memoria, hice este proceso un poco menos preciso. Después de cada 100 proyectos, verifiqué el mapa y eliminé los nombres de los archivos que ocurrieron menos de 10 veces de la lista. Podrían regresar a la próxima prueba, y si se encontraban más de 10 veces, permanecerían en la lista. Quizás algunos resultados tengan algún error si algún nombre común rara vez aparece en el primer lote de repositorios antes de volverse común. En resumen, estos no son números absolutos, pero deberían estar lo suficientemente cerca de ellos.Podría usar el árbol de prefijos para "exprimir" el espacio y obtener los números absolutos, pero no quería escribirlo, así que abusé un poco del mapa para ahorrar suficiente memoria y obtener el resultado. Sin embargo, será bastante interesante probar el árbol de prefijos más adelante.¿A cuántos repositorios le falta una licencia?
Esto es muy interesante ¿Cuántos repositorios tienen al menos algún archivo de licencia explícito? Tenga en cuenta que la ausencia de un archivo de licencia aquí no significa que el proyecto no lo tenga, ya que puede existir en el archivo README o puede indicarse mediante etiquetas de comentarios SPDX en líneas. Simplemente significa que sccno pudo encontrar el archivo de licencia explícito utilizando sus propios criterios. Actualmente, dichos archivos se consideran "licencia", "licencia", "copia", "copia 3", "licencia", "licencia", "licencia-mit", "licencia-mit" o "copyright".Desafortunadamente, la gran mayoría de los repositorios no tienen licencia. Diría que hay muchas razones por las cuales cualquier software necesita una licencia, pero alguien más lo dijo por mí.
¿Cuántos proyectos usan múltiples archivos .gitignore?
Algunos pueden no saber esto, pero puede haber varios archivos .gitignore en un proyecto git. Con esto en mente, ¿cuántos proyectos usan múltiples archivos .gitignore? Y al mismo tiempo, ¿cuántos no tienen uno solo?Encontré un proyecto bastante interesante con 25,794 archivos .gitignore en el repositorio. El siguiente resultado fue 2547. No tengo idea de lo que está sucediendo allí. Eché un vistazo brevemente: parece que se usan para verificar directorios, pero no puedo confirmar esto.Volviendo a los datos, aquí hay un gráfico de repositorios con hasta 20 archivos .gitignore, que cubre el 99% de todos los proyectos.
Como se esperaba, la mayoría de los proyectos tienen 0 o 1 archivos .gitignore. Esto se confirma por una caída masiva de diez veces en el número de proyectos con archivos 2. Lo que me sorprendió fue cuántos proyectos tienen más de un archivo .gitignore. La cola larga en este caso es especialmente larga.Tenía curiosidad por qué algunos proyectos tienen miles de esos archivos. Uno de los principales alborotadores es la bifurcación https://github.com/PhantomX/slackbuilds : cada uno de ellos tiene aproximadamente 2547 archivos .gitignore. A continuación se enumeran otros repositorios con más de mil archivos .gitignore.?
Esta sección no es una ciencia exacta, pero pertenece a la clase de problemas del procesamiento del lenguaje natural. La búsqueda de términos abusivos o abusivos en una lista específica de archivos nunca será efectiva. Si busca con una búsqueda simple, encontrará muchos archivos comunes, assemble.shetc. Así que tomé una lista de maldiciones y luego verifiqué si algún archivo en cada proyecto comienza con uno de estos valores seguido de un punto. Esto significa que el archivo nombrado se gangbang.javatendrá en cuenta, pero assemble.shno. Sin embargo, echará de menos muchas opciones diferentes, como pu55syg4rgle.javaotros nombres igualmente groseros.Mi lista contiene algunas palabras en leetspeak, como b00bsy b1tch, para ver algunos de los casos interesantes. Lista completa aquí.Aunque esto no es del todo exacto, como ya se mencionó, es increíblemente interesante observar el resultado. Comencemos con la lista de idiomas en los que más maldiciones. Probablemente, debería correlacionar el resultado con la cantidad total de código en cada idioma. Así que aquí están los líderes.Interesante! Mi primer pensamiento fue: "¡Oh, estos traviesos desarrolladores de C!" Pero a pesar de la gran cantidad de tales archivos, escriben tanto código que el porcentaje de maldiciones se pierde en la cantidad total. Sin embargo, ¡está bastante claro que los desarrolladores de Dart tienen algunas palabras en su arsenal! Si conoces a uno de los programadores de Dart, puedes darle la mano.También quiero saber cuáles son las maldiciones más utilizadas. Veamos una mente colectiva sucia común. Algunos de los mejores que encontré fueron nombres normales (si entorna los ojos), pero la mayoría de los demás seguramente sorprenderán a sus colegas y algunos comentarios en las solicitudes de la piscina.Tenga en cuenta que algunas de las palabras más ofensivas en la lista tenían nombres de archivos coincidentes, lo que me parece bastante impactante. Afortunadamente, no son muy comunes y no se incluyen en la lista anterior, que se limita a archivos con un número de más de 100. Espero que estos archivos existan solo para probar listas de permiso / denegación y similares.Los archivos más grandes por el número de líneas en cada idioma.
Como era de esperar, el texto sin formato, SQL, XML, JSON y CSV ocupan las primeras posiciones: generalmente contienen metadatos, volcados de bases de datos y similares.Nota Es posible que algunos de los enlaces a continuación no funcionen debido a información adicional al crear archivos. La mayoría debería funcionar, pero para algunos, es posible que deba modificar ligeramente la URL.¿Cuál es el archivo más complejo en cada idioma?
Una vez más, estos valores no son directamente comparables entre sí, pero es interesante ver lo que se considera más difícil en todos los idiomas.Algunos de estos archivos son monstruos absolutos. Por ejemplo, considere el archivo C ++ más complejo que encontré: COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp : son 28.3 megabytes del compilador infernal (y, afortunadamente, parece generarse automáticamente).Nota Es posible que algunos de los enlaces a continuación no funcionen debido a información adicional al crear archivos. La mayoría debería funcionar, pero para algunos, es posible que deba modificar ligeramente la URL.¿El archivo más complicado con respecto al número de líneas?
Suena bien en teoría, pero de hecho ... algo minimizado o sin saltos de línea distorsiona los resultados, haciéndolos sin sentido. Por lo tanto, no publico los resultados de los cálculos. Sin embargo, he creado un billete en sccla detección de apoyo minimización eran para sacarlo de los resultados del cálculo.Probablemente pueda sacar algunas conclusiones basadas en los datos disponibles, pero quiero que todos los usuarios se beneficien de esta función scc.¿Cuál es el archivo más comentado en cada idioma?
No tengo idea de qué información valiosa puede extraer de esto, pero es interesante verlo.Nota Es posible que algunos de los enlaces a continuación no funcionen debido a información adicional al crear archivos. La mayoría debería funcionar, pero para algunos, es posible que deba modificar ligeramente la URL.¿Cuántos proyectos "limpios"
Bajo el "puro" en los tipos de proyectos son puramente en un idioma. Por supuesto, esto no es muy interesante en sí mismo, así que echemos un vistazo en contexto. Al final resultó que, la gran mayoría de los proyectos tienen menos de 25 idiomas, y la mayoría tiene menos de diez.El pico en el siguiente gráfico está en cuatro idiomas.Por supuesto, en proyectos limpios solo puede haber un lenguaje de programación, pero hay soporte para otros formatos, como markdown, json, yml, css, .gitignore, que se tienen en cuenta scc. Probablemente sea razonable suponer que cualquier proyecto con menos de cinco idiomas está "limpio" (para cierto nivel de limpieza), y esto es solo un poco más de la mitad del conjunto de datos total. Por supuesto, su definición de limpieza puede diferir de la mía, por lo que puede concentrarse en cualquier número que desee.Lo que me sorprende es un extraño aumento en torno a 34-35 idiomas. No tengo una explicación razonable de dónde vino, y esto probablemente sea digno de una investigación por separado.
Proyectos con TypeScript pero no JavaScript
Ah, el mundo moderno de TypeScript. Pero para los proyectos de TypeScript, ¿cuántos hay exclusivamente en este lenguaje?Debo admitir que estoy un poco sorprendido por este número. Aunque entiendo que mezclar JavaScript con TypeScript es bastante común, creo que habría más proyectos en el lenguaje novedoso. Pero es posible que un conjunto más reciente de repositorios aumente drásticamente su número.¿Alguien usa CoffeeScript y TypeScript?
Siento que algunos desarrolladores de TypeScript se enferman con solo pensarlo. Si esto les ayuda, puedo suponer que la mayoría de estos proyectos son programas scccon ejemplos de todos los idiomas para fines de prueba.¿Cuál es la longitud de ruta típica en cada idioma?
Dado que puede cargar todos los archivos que necesita en un directorio o crear un sistema de directorio, ¿cuál es la longitud de ruta típica y el número de directorios?Para hacer esto, cuente el número de barras en la ruta para cada archivo y promedio. No sabía qué esperar aquí, excepto que Java podría estar en la parte superior de la lista, ya que generalmente hay largas rutas de archivos.YAML o YML?
Hubo una vez una "discusión" en Slack - usando .yaml o .yml. Muchos fueron asesinados allí en ambos lados.El debate puede finalmente (?) Finalizar. Aunque sospecho que algunos aún preferirán morir en una disputa.Mayúsculas, minúsculas o mayúsculas?
¿Qué registro se usa para los nombres de archivo? Como todavía hay una extensión, podemos esperar, principalmente, un caso mixto.Lo cual, por supuesto, no es muy interesante, porque generalmente las extensiones de archivo están en minúsculas. ¿Qué pasa si ignora las extensiones?No es lo que esperaba. De nuevo, en su mayoría mixtos, pero hubiera pensado que el fondo sería más popular.Fábricas en Java
Otra idea que se les ocurrió a los colegas al mirar algún código Java antiguo. Pensé, ¿por qué no agregar un cheque para cualquier código Java donde Factory, FactoryFactory o FactoryFactoryFactory aparece en el título? La idea es estimar el número de tales fábricas.Entonces, un poco más del 2% del código Java resultó ser una fábrica o una fábrica. Afortunadamente, no se encontró factoryfactoryfactory. Quizás esta broma finalmente muera, aunque estoy seguro de que al menos un multifactorio recursivo serio de tercer nivel todavía funciona en algún tipo de monolito Java 5, y genera más dinero todos los días de lo que he visto en toda mi carrera. .Ignorar archivos
La idea de los archivos .ignore fue desarrollada por burntsushi y ggreer en una discusión en Hacker News . Quizás este sea uno de los mejores ejemplos de herramientas de código abierto "competidoras" que funcionan juntas con buenos resultados y se completan en un tiempo récord. Se ha convertido en el estándar de facto para agregar código que las herramientas ignorarán. scctambién cumple la regla .ignore, pero también sabe cómo contarlos. Veamos qué tan bien se ha extendido la idea.Ideas para el futuro.
Me gusta hacer un análisis para el futuro. Sería bueno escanear cosas como las teclas AWS AKIA y similares. También me gustaría ampliar la cobertura de los proyectos de Bitbucket y Gitlab con análisis para cada uno, para ver si puede haber equipos de desarrollo de diferentes áreas colgando allí.Si alguna vez repito el proyecto, me gustaría superar las siguientes deficiencias y tener en cuenta las siguientes ideas.- Almacene las URL en algún lugar de los metadatos correctamente. Usar un nombre de archivo para almacenarlo fue una mala idea, ya que se pierde información y puede ser difícil determinar el origen y la ubicación del archivo.
- No te molestes con S3. No tiene mucho sentido pagar por el tráfico si lo uso solo para almacenamiento. Era mejor desde el principio meter todo en un archivo tar.
- , .
- -n , , , .
- scc, , . , CIDE.C C, , HTML. .
- , scc, , , . .
- Me gustaría agregar una detección de shebang a scc .
- Sería bueno considerar de alguna manera la cantidad de estrellas en Github y la cantidad de confirmaciones.
- Quiero de alguna manera agregar un cálculo de índice de mantenibilidad. Sería muy bueno ver qué proyectos se consideran los más reparables según su tamaño.
¿Por qué es todo esto?
Bueno, puedo tomar parte de esta información y usarla en mi motor de búsqueda y programa searchcode.com scc. Al menos algunos puntos de datos útiles. Inicialmente, el proyecto fue concebido de muchas maneras por el bien de esto. Además, es muy útil comparar su proyecto con otros. También fue una forma interesante de pasar varios días resolviendo algunos problemas interesantes. Y una buena verificación de fiabilidad scc.Además, actualmente estoy trabajando en una herramienta que ayuda a los principales desarrolladores o gerentes a analizar el código, buscar idiomas específicos, archivos grandes, fallas, etc. ... con el supuesto de que necesita analizar varios repositorios. Ingresa algún tipo de código, y la herramienta dice qué tan fácil de mantener es y qué habilidades se necesitan para mantenerlo. Esto es útil al decidir si comprar algún tipo de código base, repararlo o tener una idea sobre su propio producto que el equipo de desarrollo ofrece. Teóricamente, esto debería ayudar a los equipos a escalar a través de recursos compartidos. Algo así como AWS Macie, pero por el código, algo en lo que estoy trabajando. Yo mismo necesito esto para el trabajo diario, y sospecho que otros pueden encontrar la aplicación para tal instrumento, al menos esa es la teoría.Quizás valdría la pena poner aquí alguna forma de registro para los interesados ...Archivos no procesados / procesados
Si alguien quiere hacer su propio análisis y hacer correcciones, aquí hay un enlace a los archivos procesados (20 MB). Si alguien quiere publicar archivos sin formato en el dominio público, avíseme. Esto es 83 GB tar.gz, y en el interior hay poco más de 1 TB. El contenido consta de poco más de 9 millones de archivos JSON de varios tamaños.UPD
Varias almas buenas sugirieron colocar el archivo, los lugares se indican a continuación:Al alojar este archivo tar.gz, gracias a CNCF para el servidor para xet7 del proyecto Wekan .