metrics - studio - ¿El recuento LOC debe incluir pruebas y comentarios?

code metrics visual studio 2017 (8)

Las pruebas y comentarios deben mantenerse también. Si va a utilizar LOC como una métrica (y voy a suponer que no puedo convencerlo de que no lo haga), debe dar las tres (líneas de código real, comentarios, pruebas).

Lo más importante (y afortunadamente obvio) es que seas consecuente. No informe un proyecto solo con las líneas de código real y otra con las tres combinadas. Encuentre o cree una herramienta que automatice este proceso y genere un informe.

Lines of Code: 75,000 Lines of Comments: 10,000 Lines of Tests: 15,000 --------- Total: 100,000

De esta manera puede estar seguro de que lo hará

Completar.
Hazlo de la misma manera todo el tiempo.

Mientras que LOC (# líneas de código) es una medida problemática de la complejidad de un código, es el más popular y, cuando se usa con mucho cuidado, puede proporcionar una estimación aproximada de al menos las complejidades relativas de las bases de código (es decir, si un programa es 10KLOC y otro es 100KLOC, escrito en el mismo idioma, por equipos de aproximadamente la misma competencia, el segundo programa es casi seguro mucho más complejo).

Al contar líneas de código, ¿prefiere contar los comentarios? ¿Qué hay de las pruebas?

He visto varios enfoques para esto. Las herramientas como cloc y sloccount permiten incluir o excluir comentarios. Otras personas consideran los comentarios como parte del código y su complejidad.

El mismo dilema existe para las pruebas unitarias, que a veces pueden alcanzar el tamaño del código probado e incluso excederlo.

He visto enfoques en todo el espectro, desde el recuento de líneas no vacías no operativas "en funcionamiento" hasta "XXX líneas de código evaluado y comentado", que es más parecido a ejecutar "wc -l en todos los archivos de código en el proyecto".

¿Cuál es su preferencia personal y por qué?

No voy a responder directamente a su pregunta por una simple razón: odio las líneas de código métrico. No importa lo que estés tratando de medir, es muy difícil hacerlo peor que LOC; Casi cualquier otra medida que consideres será mejor.

En particular, parece que quiere medir la complejidad de su código. La complejidad ciclométrica general (también llamada complejidad de McCabe) es una medida mucho mejor para esto.

Las rutinas con una alta complejidad ciclométrica son las rutinas en las que desea concentrar su atención. Son estas rutinas que son difíciles de probar, podridas hasta el núcleo con errores y difíciles de mantener.

Hay muchas herramientas que miden este tipo de complejidad. Una búsqueda rápida en Google en su idioma favorito encontrará docenas de herramientas que hacen este tipo de complejidad.

Personalmente, no creo que la métrica de LOC por sí misma sea tan útil como algunas de las otras métricas de código.

NDepend le dará la métrica LOC pero también le dará muchos otros, tal complejidad ciclométrica. En lugar de enumerarlos a todos, aquí está el enlace a la lista.

También hay un complemento CodeMetric gratuito para Reflector

Un hombre sabio me dijo una vez que ''obtienes lo que medías'' cuando se trata de administrar programadores.

Si los calificas en su salida de LOC sorprendentemente, tiendes a obtener muchas líneas de código.

Si los califica en la cantidad de errores que cierran, sorprendentemente se solucionan muchos errores.

Si los califica en las funciones agregadas, obtiene muchas características.

Si los calificas en complejidad ciclomática obtienes funciones ridículamente simples.

Dado que uno de los principales problemas con las bases de código en estos días es qué tan rápido crecen y qué tan difíciles son de cambiar una vez que han crecido, tiendo a evitar el uso de LOC como una métrica en absoluto, porque conduce el comportamiento fundamental equivocado. .

Dicho eso, si tiene que usarlo, cuente sin comentarios y pruebas y requiera un estilo de codificación consistente.

Pero si realmente quiere una medida de ''tamaño de código'' simplemente tar.gz la base de código. Tiende a servir como una mejor estimación aproximada de "contenido" que contar líneas que es susceptible a diferentes estilos de programación.

Líneas de código significa exactamente eso: no se cuentan los comentarios ni las líneas vacías. Y para que sea comparable a otro código fuente (no importa si la métrica en su nombre es útil o no), necesita al menos estilos de codificación similares:

for (int i = 0; i < list.count; i++) { // do some stuff } for (int i = 0; i < list.count; i++){ // do some stuff }

La segunda versión hace exactamente lo mismo, pero tiene un LOC menos. Cuando tienes muchos bucles anidados, esto puede resumir bastante. Por eso las métricas como puntos de función se inventaron.

Depende de lo que está usando el LOC para.

Como medida de complejidad, no tanto. Tal vez los 100KLOC son en su mayoría generados por código a partir de una tabla simple, y el 10KLOC kas 5KLOC expresiones regulares.

Sin embargo, veo cada línea de código asociada con un costo de ejecución. Usted paga por cada línea mientras el programa viva: debe leerse cuando se mantiene, puede contener un error que debe corregirse, aumenta el tiempo de compilación, obtener desde el control de origen y los tiempos de respaldo, antes de cambiar o eliminarlo, es posible que necesite averiguar si alguien confía en él, etc. El costo promedio puede ser de nanopennies por línea y día, pero es algo que se suma.

KLOC puede ser el primer indicador de cuánta infraestructura necesita un proyecto. En ese caso, incluiría comentarios y pruebas, a pesar de que el costo de ejecución de una línea de comentarios es mucho más bajo que el de una expresión regular en el segundo proyecto.

[editar] [alguien con una opinión similar sobre el tamaño del código] 1

Solo utilizamos una línea de métrica de código para una cosa: una función debe contener pocas líneas de código suficientes para ser leídas sin desplazarse por la pantalla. Las funciones más grandes que eso suelen ser difíciles de leer, incluso si tienen una complejidad ciclométrica muy baja. Para su uso contamos espacios en blanco y comentarios.

También puede ser agradable ver cuántas líneas de código ha eliminado durante un refactor: aquí solo desea contar las líneas reales de código, los espacios en blanco que no ayudan a la legibilidad y los comentarios que no son útiles (que no pueden ser automatizado).

Finalmente, un descargo de responsabilidad: use métricas de forma inteligente. Un buen uso de las métricas es ayudar a responder la pregunta "¿qué parte del código se beneficiaría más de la refactorización" o "qué tan urgente es una revisión del código para la última comprobación?" - Una función de 1000 líneas con una complejidad ciclomática de 50 es un letrero de neón parpadeante que dice ''refactorízame ahora''. Un mal uso de las métricas es ''qué tan productivo es el programador X'' o ''qué complicado es mi software'' .

Extracto del artículo: ¿Cómo cuenta su número de líneas de código (LOC)? relativo a la herramienta NDepender que cuenta los números lógicos de líneas de código para programas .NET.

¿Cómo se cuenta el número de líneas de código (LOC)?

¿Cuenta la declaración de firma de método? ¿Cuenta las líneas con solo el soporte? ¿Cuenta varias líneas cuando se escribe una sola llamada de método en varias líneas debido a una gran cantidad de parámetros? ¿Cuenta "declaración de espacio de nombres" y "uso de espacio de nombres"? ¿Cuenta la declaración de interfaces y métodos abstractos? ¿Cuenta la asignación de campos cuando se declaran? ¿Cuenta la línea en blanco?

Dependiendo del estilo de codificación de cada desarrollador y dependiendo del idioma elegido (C #, VB.NET ...) puede haber una diferencia significativa midiendo el LOC.

Aparentemente, medir el LOC desde el análisis de los archivos fuente parece un tema complejo. Gracias a un astuto existe una manera simple de medir exactamente lo que se llama el LOC lógico. El LOC lógico tiene 2 ventajas significativas sobre el LOC físico (el LOC que se deduce del análisis de los archivos fuente):

El estilo de codificación no interfiere con el LOC lógico. Por ejemplo, el LOC no cambiará porque una llamada a método se genera en varias líneas debido a una gran cantidad de argumentos.
Logical LOC es independiente del lenguaje. Los valores obtenidos de las asambleas escritas con diferentes idiomas son comparables y se pueden sumar.

En el mundo .NET, el LOC lógico se puede calcular a partir de los archivos PDB, los archivos que utiliza el depurador para vincular el código IL con el código fuente. La herramienta NDependa calcula el LOC lógico para un método de esta manera: es igual al número de punto de secuencia encontrado para un método en el archivo PDB. Un punto de secuencia se usa para marcar un punto en el código IL que corresponde a una ubicación específica en la fuente original. Más información sobre los puntos de secuencia aquí. Tenga en cuenta que los puntos de secuencia que corresponden a las llaves C # ''{'' y ''}'' no se tienen en cuenta.

Obviamente, el LOC para un tipo es la suma de sus métodos ''LOC, el LOC para un espacio de nombres es la suma de sus tipos'' LOC, el LOC para un ensamblaje es la suma de sus espacios de nombres ''LOC y el LOC para una aplicación es la suma de sus ensamblajes LOC. Aquí hay algunas observaciones:

Las interfaces, los métodos abstractos y las enumeraciones tienen un LOC igual a 0. Solo se considera el código concreto que se ejecuta de manera efectiva al calcular LOC.
Las declaraciones de espacios de nombres, tipos, campos y métodos no se consideran como líneas de código porque no tienen los puntos de secuencia correspondientes.
Cuando el compilador C # o VB.NET se enfrenta a una inicialización de campos de instancia en línea, genera un punto de secuencia para cada uno de los constructores de instancias (el mismo comentario se aplica a la inicialización de campos estáticos en línea y al constructor estático).
El LOC calculado a partir de un método anónimo no interfiere con el LOC de sus métodos de declaración externos.
La relación general entre NbILInstructions y LOC (en C # y VB.NET) suele ser alrededor de 7.