2010-07-06 15 views
5

Digo entre 1 y 5 líneas. Además, debes justificar con un correo electrónico al resto de tu equipo de desarrollo. Esto ayuda a reutilizar, obliga a los buenos nombres y métodos de parejas.¿Cuál es un buen tamaño de método promedio?

¿Algún comentario?

Gracias

+2

¿Está bien tener 25 métodos de 1 línea y un método de 100 líneas? – Yellowfog

+15

Mientras sea * necesario *, el tamaño/número de líneas no es tan importante como la función ** hace una cosa **, IMO. –

+0

Personalmente, no creo que haya una respuesta definida que sea "correcta". Pero pensó que le gustaría ver una charla que hizo el "Tío Bob" Martin en QCon London este año, donde habló sobre este tema: http://www.infoq.com/presentations/Robert-C.-Martin- Bad -Código – AdaTheDev

Respuesta

1

Un poco extremo, creo que una complejidad ciclométrico de 5 o menos es una medida razonable en lugar de número de líneas. Romper el código en menos de 5 líneas podría significar que sea ilegible y laborioso. Sé que habrá diferentes pensamientos sobre esto y por eso este hilo debe ser cerrado como subjetivo.

5

1 y 5 líneas parece un límite demasiado pequeño para mí. Si está creando aplicaciones empresariales simplistas que no procesan demasiado, parece que esto está bien, pero si hay algoritmos o procesos, a menudo es mucho más legible (y fácil de mantener) escribir los pasos de procesamiento de forma secuencial en lugar de extenderse a través de múltiples métodos. o clases, incluso si es lógico para los fines de encapsulación, validación, etc.

5 líneas en muchos casos ni siquiera es suficiente para validar los parámetros e iterar a través de una colección.

Sugeriría 'about a pageful'; 20 a 30 líneas son ideales.


Por ejemplo: esto parece válida para mí, pero que se consideraría que no es bueno en 8 líneas:

// Calculates the depth of the layer in the object graph 
    public int GetIndex() 
    { 
     int ct = 0; 
     ViewLayer pos = this; 
     while (pos.Parent != null) 
     { 
      ct++; 
      pos = pos.Parent; 
     } 
     return ct; 
    } 

(me doy cuenta que estoy abriendo a mí mismo a la crítica mediante la publicación de código, pero mi point stands, este es código legible)

+2

Eso es demasiado largo, deberías haber usado algo como: 'public int GetIndex (ViewLayer pos = this) {\ n return (pos.Parent == null)? 0: 1 + GetIndex (pos.Parent); \ n} \ n' registrando en 3 líneas :-) – paxdiablo

+1

Esto no es código limpio. El código limpio para una tarea tan trivial no necesitaría ningún comentario. En primer lugar, el nombre podría haber sido DepthInObjectGraph. En segundo lugar, esto podría haber sido recursivo y tomar 1 o 4 líneas, dependiendo de si prefiere if/else o?:. – qertoip

+0

@qertiop - buen trabajo, encontraste una manera de mejorar el código, algo que casi siempre es posible. ¿Su comentario es relevante para la respuesta, es decir, usted piensa que ningún método debe ser más largo que 1-4 líneas? –

16

El tamaño del código del método es una métrica incorrecta para las responsabilidades del método. El método debe tener exactamente una principal tarea de comportamiento/creación sin duplicados de código.

1

Creo que es más complicado que eso.

Primero, los métodos tienden a seguir una distribución de ley de poder: en cualquier proyecto dado habrá algunos métodos externos que son tan inmensamente más grandes que la mayoría de los otros métodos que el tamaño promedio nunca converge.

En segundo lugar, si necesita emitir diez llamadas API para cumplir una tarea específica, no tiene sentido dividir esta secuencia de llamadas en dos métodos solo para cumplir con un límite de tamaño. Cuando divide algo en partes, debe dar dos nombres (o incluso tres) en lugar de uno. tienes que documentar cada parte, etc. En pocas palabras: lo pequeño es bueno, pero no lo sigas a ciegas. El mejor consejo es tratar de hacer que todos los métodos sean coherentes (enfocados).

1

Seguramente eso hace que el código sea más difícil de navegar y entender, A llama a B, llama a C, luego a E, luego a D, etc. No estoy seguro de cómo impone un buen nombre, tengo problemas para encontrar buenos nombres descriptivos para mis métodos existentes, nunca más uno de 5 líneas.

También hace que las clases sean más largas ya que tiene que tener la firma del método, abrir y cerrar la llave y una línea adicional para poder leer.

Además, la mayoría de mis frases linq tienen más de 5 líneas.

2

Deje que los requisitos del código dicten cuánto tiempo es demasiado largo.

¿Realmente preferirías que tus desarrolladores estuvieran gastando su tiempo escribiendo correos electrónicos en lugar de desarrollar tu código base?

Cuestiones relacionadas