language-agnostic automation metrics software-quality

language agnostic - ¿Qué métrica(s) de código lo convencen de que el código provisto es "malo"?



language-agnostic automation (27)

Líneas de código por archivo, métodos por clase, complejidad ciclomática, etc. ¡Los desarrolladores se resisten y solucionan la mayoría si no todos! Hay un buen artículo sobre Joel (no hay tiempo para encontrarlo ahora).

¿Qué código métrico (s) recomienda utilizar para identificar automáticamente el "código malicioso"?

Lo que puede convencer a la mayoría (¡no puede convencernos a todos de una métrica de mierda!: O)) de desarrolladores que este código es "basura".

¡Solo las cifras que pueden medirse automáticamente cuentan!

A veces, simplemente lo sabes cuando lo ves. Por ejemplo, esta mañana vi:

void mdLicense::SetWindows(bool Option) { _windows = (Option ? true: false); }

Solo tenía que preguntarme ''¿por qué alguien haría esto?''.

Cantidad de comentarios sin valor a comentarios significativos:

''Set i to 1'' Dim i as Integer = 1

Desafortunadamente no hay una métrica que yo sepa. Algo a tener en cuenta es que no importa lo que elija, los programadores jugarán con el sistema para que su código se vea bien. He visto que en todas partes se pone en práctica cualquier tipo de métrica "automática".

Líneas de comentarios / Líneas de código

value > 1 -> bad (too many comments)

value < 0.1 -> bad (not enough comments)

Ajuste los valores numéricos según su propia experiencia ;-)

La cobertura del código tiene algún valor, pero por lo demás tiendo a confiar más en el perfil del código para saber si el código es malo.

Los desarrolladores siempre están preocupados con las métricas que se usan contra ellos y llamar al código "malo" no es un buen comienzo. Esto es importante porque si le preocupa que sus desarrolladores jueguen con ellos, entonces no use las métricas para nada que sea para su ventaja / desventaja.

La forma en que esto funciona mejor es no permitir que la métrica te diga dónde está el código, pero usa la métrica para determinar dónde debes buscar. Lo ves teniendo una revisión de código y la decisión de cómo solucionar el problema es entre el desarrollador y el revisor. También me error del lado del desarrollador contra la métrica. Si el código aún aparece en la métrica, pero los revisores piensan que es bueno, déjelo en blanco.

Pero es importante tener en cuenta este efecto de juego cuando sus métricas comiencen a mejorar. Genial, ahora tengo una cobertura del 100% pero ¿las pruebas unitarias son buenas? La métrica me dice que estoy bien, pero aún tengo que echarle un vistazo y ver qué nos llevó allí.

En pocas palabras, el humano triunfa sobre la máquina.

Me sorprende que nadie haya mencionado crap4j .

Mi bandera de advertencia favorita: código de comentario gratuito. Por lo general, significa que el codificador no se detuvo a pensarlo; además, automáticamente hace que sea difícil de entender, por lo que aumenta la proporción de mierda.

Muchas conversiones hacia y desde cadenas. En general, es una señal de que el desarrollador no tiene claro qué está pasando y simplemente está probando cosas aleatorias hasta que algo funcione. Por ejemplo, a menudo he visto código como este:

object num = GetABoxedInt(); // long myLong = (long) num; // throws exception long myLong = Int64.Parse(num.ToString());

cuando lo que realmente querían era:

long myLong = (long)(int)num;

Número de advertencias que el compilador escupe cuando hago una compilación.

Número de líneas comentadas por línea de código de producción. En general, indica un programador descuidado que no entiende el control de versiones.

No creo que exista tal métrica. Con la excepción del código que en realidad no hace lo que se supone que es (que es un nivel adicional de crappiness), el código "malo" significa código que es difícil de mantener. Eso generalmente significa que es difícil de entender para el mantenedor, lo que siempre es en cierta medida algo subjetivo, al igual que la mala escritura. Por supuesto, hay casos en los que todos aceptan que la escritura (o el código) es mala, pero es muy difícil escribir una métrica para ello.

Además, todo es relativo. El código que realiza una función altamente compleja, en una memoria mínima, optimizado para cada último ciclo de velocidad, se verá muy mal en comparación con una función simple sin restricciones. Pero no es malo, es solo hacer lo que tiene que hacer.

Proporción de comentarios que incluyen lenguaje obsceno y comentarios que no.

Más alto = mejor código.

Tomo un enfoque de niveles múltiples con el primer nivel siendo el margen de legibilidad razonable solo por la complejidad del problema que se está resolviendo. Si no puede pasar la prueba de legibilidad, generalmente considero que el código es menos que bueno.

número de variables globales.

  • variables globales
  • números mágicos
  • relación código / comentario
  • acoplamiento fuerte (por ejemplo, en C ++ puede medir esto observando las relaciones de clase o el número de archivos cpp / header que se cruzan entre sí)
  • const_cast u otros tipos de conversión dentro de la misma base de código (no w / libs externos)
  • grandes porciones de código comentadas y dejadas allí

  • Pruebas inexistentes (reveladas por la cobertura del código). No es necesariamente un indicador de que el código es malo, pero es una gran señal de advertencia.

  • Blasfemia en los comentarios.

A primera vista: aplicación de culto de carga de modismos de código.

Apenas lo miro más de cerca: errores obvios y conceptos erróneos del programador.

  • Tenga cuidado con la proporción de clases de patrones frente a las clases estándar. Una proporción alta indicaría Patternitis
  • Compruebe si hay números mágicos no definidos como constantes
  • Use una utilidad de coincidencia de patrones para detectar código potencialmente duplicado

TODO: comentarios en el código de producción. Simplemente muestra que el desarrollador no ejecuta las tareas hasta su finalización.

Métodos con 30 argumentos. En un servicio web. Eso es todo.

Mi apuesta: combinación de complejidad ciclomática (CC) y cobertura de código de pruebas automatizadas (TC).

CC | TC 2 | 0% - good anyway, cyclomatic complexity too small 10 | 70% - good 10 | 50% - could be better 10 | 20% - bad 20 | 85% - good 20 | 70% - could be better 20 | 50% - bad ...

crap4j - posible herramienta (para Java) y explicación del concepto ... en busca de la herramienta amiga C # :(

Bueno, hay varias formas diferentes que puede utilizar para señalar si un código es o no un buen código. Los siguientes son algunos de esos:

  1. Cohesión: Bueno, el bloque de código, ya sea de clase o un método, si se encuentra que sirve múltiples funcionalidades, entonces se puede encontrar que el código tiene menor cohesión. El código más bajo en cohesión puede denominarse bajo en reutilización. Esto puede denominarse además como código de menor capacidad de mantenimiento.

    1. Complejidad del código: se puede usar la complejidad ciclomática de McCabe (número de puntos de decisión) para determinar la complejidad del código. La complejidad del código es alta y se puede usar para representar código con menos usabilidad (difícil de leer y entender).

    2. Documentación: el código con un número insuficiente de documentos también puede atribuir una baja calidad del software desde la perspectiva de la usabilidad del código.

Consulte la siguiente página para leer sobre la lista de verificación para la revisión del código.

Las métricas por sí solas no identifican el código malicioso. Sin embargo, pueden identificar un código sospechoso.

Hay muchas métricas para el software OO. Algunos de ellos pueden ser muy útiles:

  • Tamaño promedio del método (tanto en LOC / Declaraciones o complejidad). Los métodos grandes pueden ser un signo de mal diseño.
  • Número de métodos anulados por una subclase. Un gran número indica un mal diseño de clase.
  • Índice de especialización (número de métodos reemplazados * nivel de anidación / número total de métodos). Los números altos indican posibles problemas en el diagrama de clases.

Hay muchas más métricas viables, y se pueden calcular utilizando herramientas. Esto puede ser una buena ayuda para identificar código malicioso.

No hay métricas relacionadas con el estilo de codificación como parte de dicha advertencia.

Para mí, se trata de un análisis estático del código , que realmente puede estar ''encendido'' todo el tiempo:

Pondría la prueba de cobertura en un segundo paso, ya que estas pruebas pueden llevar tiempo.

No olvide que las métricas no detectan el código "cutre", sino la combinación y la evolución (como en " tendencia ") de las métricas: consulte la pregunta ¿Cuál es la fascinación con las métricas del código?

Eso significa que no solo tiene que recomendar métricas de código para "identificar automáticamente" el código malicioso "", sino que también debe recomendar la combinación correcta y el análisis de tendencias para seguir esas métricas.

En una nota al margen, comparto tu frustración ;), y no comparto el punto de vista de tloach (en los comentarios de otras respuestas) "Haz una pregunta vaga, obtén una respuesta vaga", dice ... tu pregunta merece una respuesta específica.