Pauta de codificación: ¿Los métodos no deben contener más de 7 declaraciones?

Esto es un "olor a normas" para mí. Siempre que veo estándares de codificación con límites específicos en ellos, me preocupo. Casi siempre se encuentra con un caso en el que un método debe ser más grande de lo que permite el estándar (ya sea la longitud / conteo de la línea, la cantidad de variables, la cantidad de puntos de salida, etc.). Los estándares deberían ser más como pautas y permitir suficiente margen para ejercer un buen juicio. No me malinterpretes, es bueno tener estándares, pero no deberían convertirse en "microgestión por proxy".

Por lo general, es una buena idea dividir cosas en pequeños métodos. Pero lo importante es dividir las cosas donde tenga sentido.

Si no tiene sentido dividir, entonces no dividir. Este es a menudo el caso de algunos procedimientos o códigos GUI.

Steve McConnell indicado en Code Complete que no siempre es más productivo cuando usa métodos cortos. Si se divide cuando no tiene sentido, agrega complejidad al código sin ningún beneficio.

Como siempre con las pautas, es bueno recordar por qué existen las restricciones, para que pueda aprender cuando no se aplica. En la mayoría de los códigos, los métodos serán cortos, o probablemente tenga un problema con DRY o separación de preocupaciones . Pero si no es el caso, entonces está bien.

Se debe considerar como una regla de oro.

Cosas como "No más de 80 (100,120) columnas de texto", "un punto de salida por método", "no más de 2 niveles de anidamiento", son lo que yo llamaría umbrales para los indicadores de olor de código. Si los viola en alguna ocasión, eso no significa necesariamente que el código sea malo. Si se encuentra violando las reglas constantemente, entonces algo huele en el código y puede que desee hacer una pausa y replantearse su enfoque.

Para mí, los criterios más importantes son: "¿Es comprensible este código?", "¿Es repetitivo?", "¿Está dividido en lugares lógicos?", "¿Está acoplado de manera flexible?" Hay algunos más, pero creo que la idea básica se puede resumir recordando el consejo de Donald Knuth: "Los programas deben ser leídos por humanos y solo de forma incidental para que los equipos los ejecuten".

Nunca me he tomado el tiempo de contar realmente el número de declaraciones en mis métodos, pero me esfuerzo por escribir métodos que realicen de manera limpia un solo propósito claro. Siempre y cuando su código esté limpio, sea legible y siga el DRY y Principios de Responsabilidad Única , probablemente haya hecho su trabajo. Creo que dividir arbitrariamente un método solo para imponer el límite de siete declaraciones podría hacer que su código sea menos legible / mantenible.

Es aproximado

Este tipo de reglas no deberían tomarse demasiado literalmente. Podrían haber dicho " los métodos deben ser cortos ". Sin embargo, algunas personas lo interpretaron como "menos de 1 página" y otras como "2 líneas como máximo".

Supondría que dijeron "7 declaraciones" para darte una idea aproximada (aunque creo que deberían haber dicho "aproximadamente 7"). Si necesitas 9 de vez en cuando, no te preocupes. Pero si llegas a 20, sabrás que no estás en el estadio correcto para esta regla.

7 es un número completamente arbitrario sin ningún significado.

La complejidad ciclomática es un problema mayor que el número de declaraciones. He visto un código que contenía cientos de declaraciones en un solo método (lo cual me pareció terrible), pero tenía una complejidad ciclomática de 1 y en realidad solo hacía 1 cosa. Solo había muchos pasos. Discutimos cómo dividirlo en métodos más pequeños, pero esos métodos solo serían llamados por este método.

Si bien ese es un caso bastante extremo, el punto es que necesitas mantener el código DRY y una baja complejidad ciclomática. Eso es más importante que el número de líneas en un método.

Tomemos una declaración de cambio / caso, por ejemplo. Si tiene más de 7 valores posibles, ¿necesita dividir la evaluación en múltiples métodos? Por supuesto que no, eso sería una tontería.

La división artificial del código en más métodos solo para mantener el número de declaraciones debajo de 7 solo empeora el código.

La guía debe ser Cada método debe hacer 1 cosa y mantener tu código en SECO.

Bueno, depende un poco. Escribo mucho código que accede a bases de datos. El código de la placa de la caldera para el manejo de excepciones tiene más de siete declaraciones en muchos casos. Yo diría que la mejor guía es asegurarse de que su función tenga un propósito

Todo es una compensación. El problema con el enfoque propuesto (refactorización en varios métodos y clases para que cada método sea corto) es que, aunque por diferentes motivos, conduce a un código ilegible cuando se lleva al extremo.

Imagina un método foo() que hace 7 cosas. Se podría argumentar que 7 cosas es demasiado. Tal vez en muchos casos tienes razón. Por otro lado, estas 7 cosas podrían estar estrechamente relacionadas; la lógica puede fluir suavemente y leer como prosa; Puede que no tenga problemas para entenderlo cuando realmente lo necesite. Lo que podría terminar mucho peor es tener esas 7 cosas distribuidas en un gran árbol de fuentes, de modo que si miras a foo() no tienes idea de lo que hace sin mirar en 7 diferentes lugares.

Muchas personas tienen reglas como esta en su cabeza, y el resultado es lo que yo considero como espagueti OO. Todo está limpio, encuadrado en su propio pequeño método o clase, con pequeñas micro-transacciones atómicas que ocurren en cada lugar. Pero es imposible llegar al código base y saber lo que está haciendo. Te pierdes.

no es una mala pauta. Nunca me arrepentí de haber dividido los métodos y las clases (nunca he encontrado que tuviera demasiadas) siempre y cuando estén agrupados e interrelacionados lo suficientemente bien.

El truco es NO dividirlo verticalmente (simplemente pellizque un método en un punto y comience uno nuevo). El truco, al igual que con la prueba unitaria, es tener en cuenta esta regla desde el principio para que usted realmente diseñe mejor, pasando 3 o 4 afirmaciones a mitad de método a otro método porque tener una llamada de método describe lo que está haciendo mejor que esas 3 o 4 declaraciones en medio de tu código.

Este tipo de división, incluso si es arbitraria y solo se usa una vez, puede dar lugar a mejores refactorizaciones más adelante debido a una nueva claridad de código, esto también se aplica a las clases más pequeñas.

Piense en ello como si fuera a una prueba unitaria. Si intentas agregar pruebas unitarias después del hecho, es difícil y, a veces, parece imposible, pero si lo diseñas desde el principio, en realidad mejora todo tu código.

Resumen? Si comparo el olor de diseño de "Usar menos de 7 declaraciones" con el olor de código de "Usé más de 7 declaraciones", prefiero eliminar el olor de código.

¡Guau! Nunca esperé encontrar una discusión tan intensa sobre una guía simple que aproximadamente diga que tus métodos deberían ser muy pequeños. Como siempre son desarrolladores que quieren que sus directrices sean explícitas, elijo 7 porque me pareció un buen umbral.

Algunos de ustedes ya han citado la exención de responsabilidad al principio del documento. Pero para ser claro, este documento representa una colección de pautas que intentan ayudarlo a escribir un mejor código y diseñar mejores sistemas. Nunca he declarado que cualquier cosa debería ser una regla, aunque una directriz esté marcada como nivel 1. Esos niveles son simplemente la opinión colectiva de las muchas personas que han estado usando este documento por un tiempo.

También nunca he afirmado ser un experto. Pero he estado en esta profesión durante 15 años, con aproximadamente 4 años de experiencia en C ++ y 11 años de experiencia en C #. Originalmente se basó en Industrial Strength C ++, pero lo he estado refinando desde entonces con aportaciones de la comunidad.

En cualquier caso, el punto que intentaba plantear es que debes seguir pensando por ti mismo. Si cree que la directriz de 7 afirmaciones no es útil, hágala más larga. Heck, incluso violo esa pauta de vez en cuando. Acabo de violarlo y acepto las consecuencias.

En primer lugar: es una pauta, no una regla. Se llama una guía, así que por favor trátela como tal. Esto implica que también se requiere su propio juicio (como siempre)

Aparte de eso, puedo pensar en muchos ejemplos de buenos códigos que no se adhieren a esta restricción. Aunque solo es una guía, es una mala.

Estoy de acuerdo con la declaración por encima de mí. Esto es solo una guía y en un mundo perfecto todo sería objetos, reutilizados en cada programa, y el mundo sería un lugar hermoso. No siempre es cierto y, en ocasiones, eso conllevaría una gran cantidad de recursos generales o recursos desperdiciados. También debes tener eso en cuenta.

Bastante tonto cuando agregas manejo de excepciones a la mezcla.

Después de "intentar, atrapar, finalmente", ¡te quedan cuatro declaraciones por método!

También considere un método "validateForm" para un formulario de 20 campos, incluso si maneja todas las validaciones individuales en métodos separados, todavía tiene 20 métodos de validación de campos para invocar. De acuerdo con estos lineamientos, terminaría con una división sin sentido como "validateTopOfScreen", "validateMiddleOfScreen" y "validateBottomOfScreen".

La pregunta es la combinación de "reglas" con "directrices". Las reglas deben ser obedecidas; las pautas son consejos que tienen como objetivo hacer que usted considere lo que está haciendo y si realmente podría hacerse de una mejor manera.

Yo diría que, en promedio, la mayoría de la programación probablemente se mejore siguiendo las pautas, pero siempre habrá casos en los que las pautas de manera dogmática causarán más problemas de los que debían resolver. Es por eso que no se presentan como reglas, sino como pautas.

Un respondedor anterior ha demostrado que los redactores de las directrices nunca pretendieron que se aplicaran de manera dogmática e incluyeron declaraciones a tal efecto en su documento.

Estoy de acuerdo con algunas de las observaciones anteriores. 7 para mí es arbitrario y puede ser útil en algunos idiomas donde ruby, pero para lenguajes como C #, Java, C ++ Dudo de esta convención de "7 líneas". Permítame darle un ejemplo. Mi aplicación actual tiene 22 campos de texto y hago la validación del lado del servidor. El método se llama validateInput () y mi preferencia es validar todos los campos en uno de los métodos a menos que tenga que validar algo complejo como checkEmailFormat (). Básicamente, mi código de método validateInput es 108 líneas con llamadas ocasionales a validación compleja.

Ahora imagine si llamé 25 métodos para validar cada campo. Si entra un nuevo desarrollador, tendrá que entrar y salir del método principal para saltar a través de 25 métodos que a su vez podrían estar llamando a otros pocos. Está obligado a perderse en grandes proyectos.

Lo que realmente hago para aclarar mi código es proporcionar comentarios limpios que básicamente digan lo que hacen estas 4 líneas ex -

validateInput (usuario de UserObj) {

// Validar primer nombre ....... ......

// validar apellido ...... ......

// validar correo electrónico ..... // demasiado complejo para revisar el formato de correo electrónico de expresión regular checkEmailFormat (); .... .....

y así sucesivamente .. }

Mala regla. Con el código para el manejo de excepciones, la configuración de los campos de la base de datos, la validación, ¿cómo pueden estar la mayoría de los métodos en siete declaraciones? ¿Nunca deberíamos hacer funciones lambda en línea?

Las líneas de código son un conteo arbitrario de complejidad. Con métodos de extensión puedo crear código como

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Todos los programadores junior deben ser obligados a adherirse a este principio. Eso los obligaría a pensar en la estructura de lo que están ocupados, en lugar de simplemente agregar más y más código de líneas.

Actualmente estoy viendo un método de 550 líneas de código con muchas declaraciones if else y continúa y devuelve el tejido. Es basura. Si el programador solo se hubiera visto obligado a pensar en lo que estaba haciendo ...