Consejos para escribir un código limpio

A la hora de escribir código, existe mucha diferencia entre el que lo hace bien y el que no. Escribir un buen código facilita que otros puedan utilizarlo y mantenerlo; pero también nos facilita la tarea a nosotros al poder trabajar con él después de mucho tiempo sin usarlo.
Hoy vamos a ver algunos consejos que sirven al momento de escribir código.

Indentación consistente

La indentación del código es una acción fundamental. A la hora de leer el código, el mismo debe tener los espacios y las tabulaciones necesarias para poder leerlo sin problemas. Existen varios estilos de indentación reconocidos que podemos utilizar.

Estilo K&R y BSD KNF

function saludo(sexo) {
    if(sexo = 'M') {
        alert('Buen día señor');
    } else {
        alert('Buen día señora');
    }
}

Estilo Allman

function saludo(sexo) 
{
    if(sexo = 'M') 
    {
        alert('Buen día señor');
    } 
    else 
    {
        alert('Buen día señora');
    }
}

Estilo GNU

function saludo(sexo) 
{
    if(sexo = 'M') 
      {
        alert('Buen día señor');
      } 
    else 
      {
        alert('Buen día señora');
      }
}

Elegir un estilo, es más una cuestión de gustos, ya que no modifica el funcionamiento del código. Lo importante es elegir uno y mantenerlo. Si trabajamos con código de otra gente, debemos respetar el estilo ya predefinido.

Nombres consistentes

Los nombres de las funciones, variables, clases, etc., deben ser consistentes en toda la aplicación. Se puede utilizar:

• camelCase: Las palabras se separan poniendo en mayúscula la primer letra, excepto la primer letra de la primer palabra (Java)
• CamelCase: Todas las palabras se separan poniendo en mayúscula la primer letra (.NET)
• usando_guiones (PHP)

Tener diferentes estilos, produce una situación parecida a la del punto anterior. En general, los lenguajes definen un estilo (como los indicados), con lo cual deberíamos optar por utilizarlos al momento de crear nuestro código.

Evitar comentarios obvios

Los comentarios en el código son algo muy importante para poder explicar partes del mismo que no quedan lo suficientemente claras. Mucha gente está en contra de los comentarios en el código por las siguientes razones:

• Si un bloque de código no es claro, muy probablemente esté mal declarado su nombre
• Si un bloque de código no es claro, es necesario refactorizarlo
• Los mismos no suelen mantenerse

Si optamos por agregar comentarios a nuestro código, tenemos que indicarlo sólo cuando realmente haga falta.

// función que muestra error
function mostrarError (error) {
    ...
}

Un comentario como el anterior es redundante, no agrega valor y molesta a la hora de leer el código. Esos tipos de comentarios deben ser evitados.

Evitar el anidamiento excesivo

Demasiados niveles de anidamiento pueden hacer al código difícil de leer y mantener. Por ejemplo:

function workflow() {
    if(paso1()) {
        if(paso2()) {
            if(paso3()) {
                if(paso4()) {
                    if(paso5()) {
                        ...
                    } else {
                        return false;
                    }
                } else {
                    return false;
                }
            } else {
                return false;
            }
        } else {
            return false;
        }
    } else {
        return false;
    }
}

Puede simplificarse de la siguiente manera:

function workflow() {
    if(!paso1()) {
        return false;
    }

    if(!paso2()) {
        return false;
    }

    if(!paso3()) {
        return false;
    }

    if(!paso4()) {
        return false;
    }

    if(!paso5()) {
        return false;
    }
}

Limitar el ancho de la líneas

Nuestros ojos están más acostumbrados a leer columnas angostas y altas (como las páginas de un diario), por lo cual, es importante no escribir código que sea muy ancho.
Por ejemplo, esto es más difícil de leer

SELECT id, nombre, apellido, tipoCliente FROM clientes cl INNER JOIN TiposCliente tc ON cl.tipoCliento = tc.tipoCliente WHERE apellido LIKE '%López%'

Que esto

SELECT id, nombre, apellido, tipoCliente 
FROM clientes cl 
INNER JOIN TiposCliente tc 
    ON cl.tipoCliento = tc.tipoCliente 
WHERE apellido LIKE '%López%'

En general, es una buena idea evitar escribir más allá de 80 caracteres.

Variables temporales consistentes

Es una buena idea utilizar los mismos nombres para variables temporales que cumplen el mismo rol. Por ejemplo:

// $i para bucles for  
for ($i = 0; $i < 100; $i++) {  

    // $j para bucles for anidados 
    for ($j = 0; $j < 100; $j++) {  

    }  
} 

// $k (key) y $v (value) para bucles foreach  
foreach ($some_array as $k => $v) {  

} 

De esta forma, será más simple entender cuál es el propósito de una variable a simple vista.

Refactorizar código

Refactorizar es la acción de modificar el código, sin modificar su funcionalidad. Es una especie de limpieza, en la cual cambiamos el código para:

• que se entienda mejor
• evitar bloques duplicados
• mejorar la performance

Tenemos que tener en cuenta, que al refactorizar, la aplicación debe funcionar exactamente igual que antes. Si seguimos prácticas como TDD (desarrollo dirigido por pruebas), es muy simple hacer estos cambios.

Por último

Una pequeña cita graciosa:

Codifica como si el que fuera a mantener tu código fuese un maníaco asesino que sabe donde vives.

 

Fuente: http://nebaris.com/post/65/8_consejos_para_escribir_mejor_codigo