Toda esta información está extraida en parte del imprescindible libro “Framework Design Guidelines“. Hasta dónde puedas aplicarlo dependerá de tu contexto, tipo de empresa, sector, etc. pero su lectura debería considerarse obligatoria. Voy a aprovechar para hacer una pequeña recopilación.
El mantenimiento de una guía de estilo no es sencilla y como cualquier marca de calidad que deseemos dejar en nuestros proyectos nos costará dinero. No obstante, el hábito que realmente es importante fomentar en el equipo de desarrollo es la consistencia en las prácticas más que el seguimiento de estas en concreto. Eso sí, ya que estamos enmarcando nuestros proyectos en el framework, no tendría ningún sentido no hacerlo.
La forma adecuada de utilizar las mayúsculas (Capitalization Conventions)
Hay dos tipos de codificaciones, PascalCasing y camelCasing. ¿Cuando se utiliza cada una?
PascalCasing: Nombres de clases, miembros públicos, propiedades, métodos, namespaces, etc.
camelCasing: Parámetros, variables privadas.
En cierto modo, todo lo público se escribe en Pascal, todo lo privado en camel. Se escriben en mayúsculas los acrónimos de hasta dos letras de longitud: IOStream, en caso concretario no es necesario: HtmlText .
Constructores
Los constructores son la primera operación que se ejecuta con la creación de una clase. Cuando un programador los utiliza no espera que tengan un coste excesivo, por ello un constructor debe ser sencillo y no hacer mucho más trabajo que inicializar las variables privadas (dejar el objeto en el estado que tiene que estar). Cualquier tarea más compleja debería ser un método aparte ya que esto permite una mayor riqueza de usos para el usuario de la clase (como la paralelización de ciertas tareas, o simplemente hacerle consciente de que está ejecutando una operación).
Métodos y propiedades
En muchas ocasiones a un programador le pueden surgir dudas con estas dos construcciones. ¿Hasta donde debe llegar una propiedad o cuando debería ser un método?.
¿Qué caracteriza a una propiedad?
- No dependen unas de otras
- No debería ser obligatorio llamarlas en ningún orden concreto
- No deben tener efectos colaterales sobre la instancia de la clase
- No deben lanzar excepciones
- El programador espera que se comporten como un simple campo, por lo tanto así deberían estar implementadas.
¿Qué caracteriza a un método?
- Altera de manera visible la instancia o realiza alguna conversión
- El orden de llamada es muy importante
- Devuelve un array
Codificación de los miembros de una clase
Siempre me ha generado cierta inquietud cómo debía nombrar a las variables miembro de una clase. Realmente, al usarlas en una función, es ideal utilizar la palabra reservada this para que de un solo vistazo se pueda indicar al lector del código que estamos hablando de una de estas variables. Otro modo es prefijar de algún modo estas variables (“m_Variable”). Aunque esto no está soportado mayoritariamente es interesante un comentario de Anthony Moore (Equipo BLC del Framework) con el cual coincido. Según él, el prefijado de estas variables puede evitar errores de programación entre variables locales y variables miembro, además de permitir diferenciarlas también de variables estáticas.
Espero que os sea de utilidad.
