Nomenclatura y estilo (II)

Bueno, vamos con la diversión.

Antes de comenzar he de decir que debes tener una guía de estilo para tu empresa o proyecto, y que esa será tu guía. Hay muchas cosas acerca de las guías de estilo que se pueden considerar subjetivas, y variarán dependiendo del lector.

Pongo un enlace a una guía bastante completa de Philips para C#, que es muy específica de C# pero que tiene muchas cosas aplicables a cualquier lenguaje orientado a objetos. Tengo que decir que no estoy de acuerdo con todos los puntos de esta guía, y que echo de menos algunas explicaciones en ella, aunque es algo razonable teniendo en cuenta de que se trata de una guía impuesta a un grupo de desarrollo, y no una discusión como la que hacemos aquí.
Creo que este documento mezcla conceptos de nomenclatura, formato de código y estilo de código, que son diferentes para mí. Ya he hablado de nomenclatura, y volveré a hacerlo más adelante. El formato de código hace referencia a la apariencia del código, y cómo hacer para que sea más legible, y además es menos específico del lenguaje. El estilo de código por el contrario, se refiere a técnicas de codificación y cómo escribir mejor código. Las tres cosas son esenciales, y en casos concretos como la guía Philips puede tener sentido mezclarlas, pero yo prefiero mantenerlas apartadas (juntas pero no revueltas).

Voy a comenzar hablando sobre el Formato de Código, exponiendo primero las cosas objetivas y explicando su razón. Luego seguiré con las subjetivas, relacionadas fundamentalmente con espacios y longitudes. Por último hablaré sobre el Estilo de Código, dividiéndolo de igual manera.

Debes recordar que este es mi blog y, por tanto, escribo aquí mis propios pensamientos y preferencias, que pueden ser diferentes de los tuyos. Generalmente estoy a cargo de definir todo este tipo de políticas en el trabajo, y de obligar su cumplimiento. Si, obligar; cuando trabajas para una compañía debes seguir sus guías de trabajo, aunque sean diferentes de las tuyas. Cuando estés desarrollando en casa, o dejes la compañía, podrás usar tus propias reglas.

Comencemos.

Declaración de variables
Estoy de acuerdo con la guía en que las variables deben ser declaradas allí donde se usen, en lugar de ponerlas todas juntas al comienzo del método. Esta es una de las capacidades añadidas en C++ respecto a C, y una buena. Si declaras una variable junto al bloque en que se usa estás facilitando el refactoring del código, porque puedes tomar todo el bloque y llevarlo a otro método, por ejemplo; y si resulta que quieres borrar el bloque no corres peligro de dejarte olvidada la variable. Además, al poner la variable junto al bloque en que se usa mejoras la comprensión sobre su cometido.

Bloques de control
De nuevo estoy de acuerdo. Toda sentencia de control (if, while, etc.) debe estar seguida de un bloque de control, aunque esté vacío. A pesar de que C++, C# y java te permiten no utilizar llaves para bloques simples (de una línea) es algo muy propenso a errores: si después añades una línea al bloque, es fácil que olvides poner las llaves, con lo cual el programa compilará pero no funcionará correctamente. Este tipo de errores suelen ser muy difíciles de encontrar.

Usa espacios, no tabuladores
Muchos dirán que esto es algo subjetivo, pero yo digo que no lo es. La razón es simple: los espacios son la única forma de garantizar que la intentación permanece consistente independientemente del sistema. Usualmente, diferentes sistemas muestran los tabuladores de forma distinta, y no sólo aplica a pasar de Windows a Unix, por ejemplo, sino entre diferentes programas en un mismo sistema operativo. La parte subjetiva es cuantos espacios utilizar para la indentación. Yo uso cuatro, pero es subjetivo.

Indentación
Debes usar un estilo de indentación bueno y consistente. Eso es objetivo. El resto del asunto es subjetivo, y creo que haré un post al respecto con mis propias preferencias. La indentación está muy relacionada con la máxima longitud de línea, cosa de la que hablaré en el siguiente post.

Y esto es lo poco que puedo considerar objetivo acerca del Formato de Código.

Philps' C# Coding Guidelines