Hay muchas formas de programar, pero no todas son igualmente comprensibles. Por eso, especialmente en compañías grandes, se suele elaborar una guía de estilo de programación que recoge reglas de codificación: como separar código en ficheros y directorios, como elegir a nombres para variables y funciones, cómo alinear la sangría de un bloque etc. Hay muchas versiones y ninguna es perfecta. En este artículo no queremos proponer una guía de estilo más, sino dar unos consejos como elaborar una.

Una guía de estilo de programación sirve para unificar la manera de crear código. Un código desconocido es más fácil de entender si las mismas cosas se hacen de la misma manera. Un programador nuevo en el proyecto tarda menos tiempo en entenderlo. Aunque puede ser obvio guardar una clase en un fichero con el mismo nombre, no es requerido por el lenguaje. Y lo que no está requerido se hace. Hay más que un caso que un proyecto en producción se llama “new Project” o lo que la IDE propone por defecto. Meter todo en un fichero es más rápido que usar varios ficheros y llamar a variables i, x y a requiere menos esfuerzo que buscar una solución más literaria.

También es cierto que una guía de estilo afecta a la programación como un plan de tareas de hogar a un piso de estudiantes: la limpieza impone el más guarro. Cualquier definición de estilo no sirve si los programadores no aportan la disciplina necesaria para emplearla. Si los supervisores se cortan a pedir a los programadores a reeditar un fichero porque, por ejemplo, el código está mal alineado, entonces el estilo acabará ser uno más o menos similar a la guía. Esto puede ser un problema si el estilo del código es un criterio de calidad – a veces hasta contractualmente fijado con el cliente.

Al mismo tiempo revela también el peligro de imponer un estilo demasiado exigente. Cuyo carácter tiene un sentido de orden, siempre buscará una manera ordenada de escribir código. Una persona desordenada va a pasarse de cualquier regla si no se supervisa constantemente. Por lo tanto es importante no pedir demasiado y pedir algo justificado. En grupos pequeños no podría ser mala idea de dejar a todos opinar sobre una propuesta de estilo que luego será obligatoria para todos.

Reglas que una guía no demasiadamente exigente podría establecer son:

  • Se define una clase por fichero y este fichero se llama igual que la clase.
  • Se define donde guardar los ficheros fuente y donde los ficheros compilados para poder usar un control de versiones.
  • Se define abrir llaves en una línea nueva – o se usa la notación de Kernighan and Ritchie(o de Java) con la llave { en la misma línea.
  • Se define la sangría como 4 espacios y se descarta tabuladores.
  • Se puede exigir poner comentarios en estilo de javadoc u otra herramienta de documentación automatizada.

Una buena guía de estilo ayuda a evitar errores desde el principio. Por ejemplo, pedir que se asigne NULL a un puntero tras liberar la memoria a que apunta no aparece en ninguna referencia del lenguaje. Sin embargo, esta medida puede ahorrar errores difíciles a localizar. Propuestas igualmente útiles pueden ser

  • Asignar un valor cero a cualquier identificador que apunta a un recurso liberado – que pueden ser un “handler” de una ventana, el id de un evento registrado, referencias a memoría u objetos dinámicamente creados.
  • Obligar el uso de un namespace o prefijos para evitar conflictos de nombres con bibliotecas estándares. Igualmente se puede prohibir el uso del guión bajo como primera letra de un nombre de una variable no privada.
  • Usar una forma estandarizada de formar identificadores como CamelCase, notación húngara o separar nombres compuestas por guión bajo. El estilo puede fijar si nombres que contienen abreviaturas las convierten en minúsculas – algo como loadXML o loadXml.
  • Respecto a los nombres puede haber un énfasis especial a letras y números que fácilmente se confunden como o y 0 o i, j, l, I y 1.
  • Se pueden fijar en qué orden aparecen miembros públicos y privados en una clase.

Como en todo, hay que evaluar el beneficio de más reglas que, en principio, sólo complican el trabajo. En todo caso, un estilo debe ser fijado al principio de un proyecto. Para una compañía pequeña puede ser una buena idea adherirse a un estilo popular como el de Sun para Java o él de la biblioteca STL para C++.

Anuncios