Otra de las series de charlas más conocidas de Crockford, son en las que habla de la importancia del estilo de código que empleamos.
A good style can help produce better programs. Style should not be about personal preferences and self-expression. Douglas Crockford
De esta serie creo que la más interesante es:
- YUIConf 2011. 66′. Douglas Crockford. Programming Style & Your brain. En esta charla Crockford explica lo importante que es usar un estilo de código adecuado, y como hay estilos mejores que otros (según el lenguaje que estemos usando). Al programar no debemos tratar de demostrar lo listos que somos, si no escribir código para que otros puedan entenderlo, y hay estilos que favorecen esto además de reducir los bugs que podamos cometer. La charla se centra en Javascript y la herramienta JSLint, pero el porqué de usar un estilo y herramientas es importante vale para cualquier lenguaje.
Otras charlas similares serían:
- HTML5 Dev Conf 2011. 36′. JavaScript Programming Style and Your Brain with Douglas Crockford. Es una versión reducida de la charla, contempla menos casos que en las otras.
- JaxConf 2012. 54′. Douglas Crockford: Programming Style & Your Brain. Bastante completa, pero un poco más aburrida que la larga.
Escogiendo un estilo de código
Crockford dice que al escoger un estilo, debemos priorizar (y en ese orden) que:
- Evite errores (aunque sea errores que raramente sucedan)
- Sea legible. Comuniqué claramente su intención al resto de programadores. Y se debe preferir esto sobre ahorrar memoria o velocidad.
Algunos comentarios de estilo de su charla con los que estoy de acuerdo
La llave va a la derecha
La llave va a la derecha, porqué el siguiente código en js produce un error silencioso:
[cc lang=»javascript»]
return
{
ok: false
};
[/cc]
Mientras que esto funciona correctamente:
[cc lang=»javascript»]
return {
ok: false
};
[/cc]
Usar Strict Equality Comparison
No usar nunca «==» usar siempre «===». Evita resultados indeseados al hacer casting.
No usar el slash para generar strings multilínea
No usar el slash para generar strings multilínea porqué si hay un espacio después del slash se produce un error
[cc lang=»javascript»]
«hola \
mundo»
[/cc]
Usar siempre las llaves para los bloques de código
Usar siempre las llaves aunque sea para escribir en la misma linea [cci lang=»javascript»]if (flag) { doSomething(); }[/cci]
No usar pre/post incremento
No usar pre/post incremento. En lugar de ++x o x++ usar x+=1; Los primeros casos obligan a pensar más en lo que se está haciendo de que valor va a tener x cuando se ejecute algo, e introduce más errores.
No usar asignación transitiva
No usar la asignación transitiva var a = b = 0. Porqué no está claro si lo que se quería hacer era
[cc lang=»javascript»]
var a = 0,
b = 0;
b = 0;
var a = b;
[/cc]
En los switch usar siempre break
En el switch usar siempre break después de cada caso. Es muy fácil usarlo mal, y que se presente un bug difícil de depurar.
Forma de usar las IIFE
Al usar Immediately Invocable Function Expression, preferir la tercera forma que aparece aquí
[cc lang=»javascript»]
function () {
…
}(); // Syntax error!
(function () {
…
})(); // Bien
(function () {
…
}()); // Mejor. Queda más claro lo que estamos haciendo según Crockford
[/cc]
Usar siempre el «;»
Usar siempre el ; para evitar el Automatic Semicolon Insertion que puedo provocar bugs difíciles de depurar.
Algunos con los que puedo estar de acuerdo, pero debería revisar
Declaración de variables en el top
Como javascript no tiene (¿tenía?) block scope, si no sólo function scope, hay que declarar todas las variables en la parte de arriba y declarar todos los métodos antes de usarlos. Esto deja claro como funciona el hoisting en javascript que puede introducir errores. Esto incluye el no declarar variables dentro del for – for (var i …) {, para dejar claro que la variable i es válida para toda la función, y tiene valor antes (undefined) y después del for (el último valor que haya tomado en el bucle). Habría que ver como se conjuga esto con let, const, …
Espacio entre paréntesis y resto de elementos
Una serie de reglas sobre donde y como usar los paréntesis, del tipo:
- No space before ( when used to invoke a function
- No space between a function name and a parameter list
- One space between all other names and (
Uso equivocado según crockford:
- foo (bar);
- function foo (b) {…}
- function(x) {…}
- return(a+b);
- if (a=== 0) {…}