Lidiando con la sopa de llaves

He programado en C # y VB.NET durante años, pero principalmente en VB. Estoy haciendo un cambio de carrera hacia C # y, en general, me gusta más C #.

Sin embargo, un problema que tengo es la sopa de llaves. En VB, cada palabra clave de estructura tiene una palabra clave de cierre coincidente, por ejemplo:

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

El mismo código escrito en C # termina siendo muy difícil de leer:

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

Al estar tan acostumbrado a VB, me pregunto si hay una técnica empleada por los programadores de estilo c para mejorar la legibilidad y garantizar que su código termine en el "bloque" correcto. El ejemplo anterior es relativamente fácil de leer, pero a veces al final de un fragmento de código tendré 8 o más niveles de llaves, lo que me obliga a desplazarme por varias páginas para descubrir qué llave termina el bloque que me interesa. en.

Coloque su llave inicial en el mismo "rango" que la final, de esta manera:

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• Dependiendo de su IDE: coloque el cursor en la llave de apertura / cierre y resaltará tanto eso como la llave correspondiente.
• Contraiga el bloque y le mostrará dónde se abre / cierra.
• Escribe bloques de código más pequeños. Seriamente. Echa un vistazo Clean Codey nunca más te encuentres con este problema (y ten un código más legible / mantenible).

Una nota, la siguiente es una sintaxis válida de C # que podría ayudar a su situación particular:

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

Una convención común es agregar un comentario después de la llave de cierre para indicar la estructura que se está cerrando:

if {
   ...
} // end if

while (condition) {
   ...
} // end while

Nunca me he acostumbrado a esta convención, pero a algunas personas les resulta útil.

En general, cuando se hace difícil hacer coincidir las llaves en cualquier estilo, probablemente significa que el método es demasiado largo y debe ser refactorizado.

Creo que necesitas resistirlo con los frenos. Eventualmente se convertirán en una segunda naturaleza para ti y te preguntarás cómo has vivido sin ellos.

Sin embargo, asegúrese de que estén sangrados adecuadamente y de que se sigan algunas convenciones de espaciado (no importa cuál).

Elimino 2 niveles de anidamiento al contraer horizontalmente el espacio de nombres y los ámbitos de clase. Observe que los métodos están alineados con el borde izquierdo de la pantalla. No veo el punto de perder 2 niveles de sangría en cada archivo.

Después de eso, es raro que alguna vez anides más de 4 niveles de profundidad.

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

Recientemente decidí intentar formalizar dos reglas sobre construcciones de control de flujo que básicamente son así:

• No debería tener más que construcciones de flujo de código necesarias
• Debe hacer que las construcciones de flujo de código sean lo más pequeñas posible

Por exactamente las razones que ha mencionado y de las que está al tanto, creo que estas son excelentes reglas a seguir. Hay un par de técnicas simples que puede emplear para lograrlas:

• Salga del alcance lo antes posible (esto incluye el alcance de los bucles y las funciones)
• Esté atento a los elses que podrían mitigarse al salir de la función del anterior si y aplique la técnica de salida del alcance como mencioné
• Invierta sus verificaciones condicionales cuando el código dentro de un if sea mejor que el de afuera
• Factoriza el código dentro de un bucle a otro método cuando el tamaño del bucle crece para oscurecer el resto del método
• Esté atento a cualquier ámbito que solo contenga otro ámbito, por ejemplo, una función cuyo ámbito completo se llena con un if sin nada fuera del if

He detallado aquí ejemplos de cómo no seguirlos puede terminar con usted haciendo lo que dijo y colocando el código en el bloque de código incorrecto, lo cual es malo y una causa fácil de que surjan errores durante el mantenimiento.

Desafortunadamente, esta es una de las causas más antiguas de guerra en informática. Se pueden hacer argumentos razonables desde ambos lados (mejor economía de bienes raíces vertical versus capacidad más fácil de combinar visualmente la llave de apertura con la llave de cierre), pero en realidad un simple formateador de código fuente resolverá todo por usted. MS Visual C # tiene uno incorporado que funciona bien.

Sin embargo, tenga en cuenta que si está trabajando como parte de un equipo, se espera que cumpla con las convenciones utilizadas por ese equipo, por lo que vale la pena familiarizarse con ambos estilos y abstenerse de ser religioso sobre los estilos de aparatos ortopédicos.

Por lo tanto, mientras aprende por todos los medios, enfóquese en el estilo que le facilita aprender, pero vigile el otro mientras lo hace y le irá bien.

Use Resharper, que le ayudará a recomendar formas de reducir la anidación. Además, lea el libro Clean Code de Bob Martin , que enfatiza que una función solo debe hacer una cosa y, por lo tanto, cada función solo debe tener media docena de líneas de largo, por lo que no tendrá que preocuparse por tantos niveles de anidamiento.

Hay un complemento para el editor que puede ayudarlo en: C # Outline .

El complemento extiende el editor VS20xx para C # al agregar funciones para contraer, expandir y resaltar bloques de código anidados. Estas características permiten una edición y lectura más fáciles de contenidos anidados de bloques de código como if, while, etc.

Si escribe su código en Visual Studio, también hay un complemento que le muestra puntos verticales entre el principio y el final de cada estructura que construya.

Pero, en general, creo que tomará algún tiempo hasta que te acostumbres a la "sopa de llaves". (Por cierto, me gusta mucho esa expresión. Suena un poco como un Nombre de Episodio para The Big Bang Theory)

La sangría te dice dónde estás, en ambos estilos de sintaxis. Si escribe un programa VB o un programa C # en una sola línea, pronto no podrá saber en qué parte de la sintaxis anidada se encuentra. La máquina analiza las frases finales de bloque o llaves, pero los humanos necesitan sangrado.

Las frases finales de bloque provienen de una era de tarjetas perforadas y cinta de papel, cuando la programación era mucho menos interactiva y visual. O, realmente, no es interactivo en absoluto. Era difícil ingresar a los programas, por lo que los programadores necesitaban compiladores para ser muy inteligentes sobre el análisis de sintaxis y la recuperación de errores.

En esa época pasada, el ciclo de edición-compilación-ejecución podría haber consistido en preparar tarjetas perforadas con un perforador de tarjetas, y luego alinearse en una ventana de envío de trabajo donde un empleado tomó las tarjetas perforadas y las envió a la máquina. Más tarde, el programador recolectaría la salida (impresa en papel) de otra ventana. Si el programa tuviera errores, la salida consistiría solo en el diagnóstico del compilador. Cuando los tiempos de respuesta son largos, el costo adicional de escribir en end iflugar de solo )se justifica si ayuda a mejorar la calidad de los diagnósticos, porque el programador necesita corregir tantos errores como sea posible en una sola iteración para reducir la cantidad de tiempo perdido iteraciones a través de la ventana de envío de trabajos.

Cuando falta una llave de cierre, es difícil saber qué llave abierta es la que no está cerrada. (Es posible que el compilador tenga que analizar la sangría para hacer una suposición informada). Si elimina una llave de cierre dentro de una función, parece que todo el resto del archivo es parte de esa función, lo que resulta en una ráfaga de mensajes de error inútiles. Mientras que si tiene una end functionsintaxis, el compilador puede deducir dónde termina la función errónea, recuperar y analizar las funciones subsiguientes correctamente, proporcionándole diagnósticos adicionales, si los hay, que sean significativos.

Cuando trabajas en un editor de texto con reconocimiento de código que sangra y colorea automáticamente tu código, en una pantalla de alta resolución donde puedes ver sesenta o más líneas, los argumentos para ese tipo de lenguajes torpes ya no se aplican. Puede editar y reconstruir progresivamente programas tan rápido que puede lidiar con un error a la vez. Además, al ver grandes secciones del programa simultáneamente en la pantalla y mantener una sangría adecuada, puede reducir la aparición de ese tipo de errores de anidación en primer lugar. Y un buen editor de texto de programación incluso marcará algunos tipos de errores de sintaxis mientras escribe. Además, hay editores plegables que colapsarán los bloques de un programa en función de su sintaxis, dando una vista "esquemática" de su estructura.

Lisp usó paréntesis desde el principio y quizás, no por casualidad, los piratas informáticos de Lisp fueron pioneros en la programación como una experiencia interactiva al construir sistemas que aceptaban programas en pequeños fragmentos (expresiones).

De hecho, no necesita símbolos finales, como lo ilustra el lenguaje Python. La ideación puede ser simplemente la estructura. Los humanos ya usan sangría para asimilar la estructura del código, incluso en idiomas en los que la máquina se basa en símbolos o frases finales.

Si está utilizando un IDE, simplemente presione Crtl+ k+ Dy el IDE hará el resto del trabajo.