Recientemente descubrí que en varios equipos diferentes, el uso de espacios en sus estándares de codificación varía enormemente. Esto despertó mi curiosidad, porque siempre he pensado que debería haber un hábito universalmente reconocido como el mejor para el uso de espacios en el formato del código. Pero en el desarrollo real, parece que no existe tal uniformidad.

Situación actual

Primero, veamos los hábitos de estilo del código Java en la mayoría de los IDE de Java.

A continuación, un ejemplo:

public class Example {

public static void main(String[] args) {
    int answer = 2 + 4 * 6;
    for (int i = 0; i < 5; i++) {
        doSomething();
    }
    System.out.println("The answer is " + answer);
}

    private static void doSomething() {
        // something
    }
}

Ten en cuenta que este es el estilo más común entre los programadores de Java y otros lenguajes similares a C.

No hay espacios en el interior de los paréntesis. Solo cuando hay una palabra clave como `for` o `while` delante de los paréntesis, aparecen espacios entre ellos, pero no hay espacio entre el nombre del método y los paréntesis que le siguen. Sin embargo, siempre hay un espacio antes de la llave de apertura (que generalmente aparece al final de la línea). Los operadores matemáticos siempre están rodeados de espacios. Y no hay espacio antes del punto y coma.

Si lees código con frecuencia, quizás pienses que esta es una disposición muy natural, pero si no eres programador, podrías pensar que estas reglas son demasiado arbitrarias, con muchas inconsistencias, excepciones y puntos que debatir.

Por favor, deja más espacio para tu código

En mi proyecto de desarrollo actual, hay dos equipos principales de desarrollo en la empresa: uno es el equipo Load Test Products (LTP) y el otro es el equipo Functional Test Products (FTP). Los dos equipos siguen ciertos hábitos de estilo de codificación, y ambos son particularmente generosos en el uso de espacios, como en el ejemplo del siguiente fragmento de código:

public class Example
{

    public static void main( String[] args )
    {
        int answer = 2 + 4 * 6;
        for( int i = 0; i < 5; i++ )
        {
            doSomething();
        }
        System.out.println( "The answer is " + answer );
    }

    private static void doSomething()
    {
        // something
    }

}

Este estilo hace que el código parezca menos denso y más uniforme (por ejemplo, no hay espacio antes de los paréntesis de apertura, y hay espacios en los lados interiores de todos los paréntesis, llaves y corchetes). No digo que sea mejor o peor que el estilo anterior... simplemente es más fácil distinguir las palabras. El costo es que en una pantalla solo se muestra menos código.

Aunque cada estilo de codificación tiene sus ventajas y desventajas, me sorprendió que el equipo de desarrollo de FTP finalmente decidiera cambiar al estilo de codificación más común mencionado anteriormente. Consideraron que valía la pena hacer el cambio, e incluso lo discutieron, así que creo que pensaron que era importante. Su criterio no fue que uno fuera mejor que el otro... Creo que se centraron principalmente en quién estaba acostumbrado a ese estilo, porque la mayoría de nuestros productos son de código abierto, y esa es una razón importante para que sea más fácil que los programadores de la comunidad donen código.

En mi equipo, el equipo LTP, seguimos manteniendo nuestro estilo y no tenemos la intención de hacer ningún cambio. Al menos para mí, esta es una decisión basada en consideraciones técnicas: si el otro estilo de codificación no muestra ninguna ventaja (y nuestro proyecto tiene poca necesidad de donaciones de código abierto), ¿por qué cambiar a otro estilo?

Las reglas necesitan unificarse

He estado donando código a proyectos de código abierto, como el lenguaje de programación Ceylon, y me sorprendió mucho que no siguieran ningún estilo de codificación en absoluto. Puedes escribir código con cualquier estilo que te guste.

Quizás a algunos programadores que se sienten abrumados por las numerosas normas de codificación en algunas empresas les guste esto, pero creo que si no hay un conjunto de estándares de codificación, es muy probable que el código de tu proyecto se vuelva caótico en cuanto al formato. Cada donante de código trae su propio estilo al código que envía, y no es de extrañar; el resultado es que todo el código es variopinto, y puedes ver una gran variedad de estilos en las pocas líneas de código siguientes:

while (exists cell = iter) {
        if (exists elem = cell.element,
        elem==element) {
            last = cell;
        }
        iter = cell.rest;
    }
}

if (exists cell=last){
    cell.element=replacement;
    return true;
}
assert (0<=index<length);

La pregunta principal que quiero plantear es: ¿es realmente el estilo de codificación una práctica de desarrollo importante? ¿Cuánto impacto tiene en la eficiencia de los programadores a la hora de desarrollar software?

Creo que esta pregunta está relacionada con otra similar: ¿el formato del código afecta la legibilidad del código?

El formato del código afecta la legibilidad del código

Creo que esta pregunta es muy fácil de responder. ¡Claro que afecta! Escanea con los ojos las siguientes dos piezas de código (tomadas del proyecto Ceylon) línea por línea, y sentirás fácilmente cuál es más legible. – CeylonCreate)?

function validModuleNameChar(Character c)=>c.letter||c.digit||c in ['_','.' ];
if (!trimmedName.empty,
    validModuleNameFirstChar(trimmedName.first else 'X'),
    trimmedName.every(validModuleNameChar),
    !(trimmedName.split('.'.equals,true,false)).containsAny(ceylonKeywords.chain {""})) {
    return trimmedName;
}
function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

Quizás la diferencia sea pequeña, pero si pasas mucho tiempo leyendo mucho código todo el día, la diferencia es grande.

Lecciones aprendidas de la escritura de texto común

Hablando de legibilidad del código, quizás deberíamos observar la capacidad más común de las personas para leer texto, que se ha desarrollado durante miles de años, ¡así que debería haber conclusiones de mejores soluciones!?

En el inglés 'corriente', puedes ver el uso convencional de los espacios, pero no verás a los escritores discutiendo si deberían usar espacios alrededor de los paréntesis. Entonces, ¿cómo sería si el código se escribiera como el inglés 'corriente'?

Volvamos al ejemplo sencillo de arriba:

function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

La mayoría de las cosas en el código son como las oraciones en inglés corriente. Usas paréntesis para 'agrupar' ciertas palabras. Usas espacios entre palabras y símbolos; aquí encontramos una diferencia con los hábitos de codificación comunes: al llamar a un método, no hay espacio entre el nombre del método y los paréntesis, y no se deja espacio en blanco después del operador punto.

Puedo entender por qué no hay espacios en estos lugares, porque en el código estos paréntesis o puntos representan una relación de 'pertenencia' o asociación. Pero, ¿es realmente necesario apretar ese espacio para representar esa relación? ¿No se siente más claro cuando vemos el código de ejemplo anterior?

Otra cosa que no existe en el inglés corriente son las expresiones anidadas... por lo tanto, tenemos situaciones que no aparecen en la escritura del inglés corriente. Pero no es un gran problema, solo hay que recordar una regla general: añadir espacios a ambos lados de los símbolos.

¿Sientes que el código anterior es un poco extraño? Debo admitir que se ve un poco incómodo, aunque creo que es solo porque aún no estoy acostumbrado.

Aunque aún no estoy acostumbrado, estoy seguro de que este código es más fácil de leer y entender.

Puedo decir claramente que si todo el código siguiera este hábito, el proceso de lectura de código para nosotros los programadores sería mucho más fácil.

Conclusión

Espero que ningún programador piense que seguir un estándar de codificación predefinido dificulta la programación.

En primer lugar, todos los IDE se pueden configurar para ajustar automáticamente el formato del código. Puedes escribir el código de forma desordenada, pero al final no olvides usar los atajos de teclado del IDE para ordenar el código antes de enviarlo. Del mismo modo, supongo que ningún escritor cree que el formato de escritura sea demasiado estricto como para limitar su creación.

Afortunadamente, he descubierto que en todos los estilos y normas de codificación actuales, el uso de espacios no tiene grandes problemas. Pero usar más espacios seguramente hará que el código sea más claro y legible.

Texto original en idioma extranjero:Give your code some space!

Fuente de información:Revista extranjera de comentarios de TI