Una referencia rápida para distintos tipos de patrones de diseño de dos páginas. Puedes descargártela de McDonaldLand.info.

El otro día estuve hablando un poco sobre qué son los patrones de diseño. Vimos que nos podían ayudar resolviéndo algunos problemas que se nos pueden presentar durante el desarrollo de nuestros proyectos. Pues bien, dependiendo del problema al que nos enfrentemos, podemos agrupar los patrones en tres grandes grupos:

• Patrones de creación. Estos patrones se utilizan cuando debemos crear objetos pero debemos tomar decisiones dinámicamente en el proceso de creación. Para ésto lo que hacemos es abstraer el proceso de creación de los objetos para realizar la decisión de qué objetos crear o cómo crearlos para el momento en que se tenga que hacer. Patrones de creación son: Abstract Factory, Builder, Factory Method, Object Pool, Prototype y Singleton.
• Patrones estructurales. Nos describen como utilizar estructuras de datos complejas a partir de elementos más simples. Sirven para crear las interconexiones entre los distintos objetos y que estas relaciones no se vean afectadas por cambios en los requisitos del programa. Algunos ejemplos de patrones estructurales son: Adapter, Bridge, Decorator, Facade, Flyweight y Proxy.
• Patrones de comportamiento. Fundamentalmente especifican el comportamiento entre objetos de nuestro programa. Hay varios: Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento (o Snapshot), Observer, State, Strategy, Template Method y Visitor.

La semana pasada tuve en el trabajo un minicurso de 2 días sobre patrones de diseño. Para quien no lo sepa, según la wikipedia:

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Esto es, soluciones a problemas que se nos pueden presentar en nuestros desarrollos que ya han sido probadas por otros que se enfrentaron a estos mismos problemas y que, por tanto, se ha mostrado su efectividad.

Siguiendo con el curso, éste se dividía en dos: enfocado a los diseñadores y enfocado a los constructores. Estuvimos primero viendo los patrones generales más típicos: singleton, factory, builder… la gran mayoría de los que aparecen en el enlace anterior de la wikipedia. Y después nos adentramos más en conocer los patrones que utilizamos (o deberíamos utilizar) en el trabajo: los patrones en J2EE. Por último, y no menos importante, vimos una serie de antipatrones que muchas veces utilizamos en nuestro trabajo diario y que deberíamos evitar (apoyado por una serie de buenas prácticas que nos facilitarían la escritura de código). Por cierto, ahora que hablo sobre antipatrones, leyendo mis feeds me encontrado con un buen artículo de VariableNotFound.

En fin, que el curso estuvo bastante bien (todo sea por desarrollar software de mayor calidad) porque desconectamos un poco del día a día en el trabajo. Quizás en próximos posts hable algo más sobre patrones de diseño.

Me he encontrado con este artículo con unas 50 buenas prácticas en CSS:

A evitar

1. CSS in-line.
2. Tamaños de fuente absolutos.
3. Marcar con comillas simples las rutas de las imágenes.
4. CSS hacks.
5. Redeclarar valores heredados.
6. Aplicar paddings/borders y un ancho fijo a un elemento.
7. !important y position: absolute.
8. Nombrar clases/IDs según su apariencia.

Buen estilo

9. Declaraciones CSS una por línea.
10. Comentar el código.
11. Organizar el fichero CSS.
12. Indentar tanto como sea necesario.
13. Hacer el código fácil de leer.
14. Usar un sistema común de nombrado.
15. Declaraciones cortas alfabéticamente.
16. Un “;” no es necesario en la última declaración.
17. Si declaras una unidad de 0 px/em/%/… puedes omitir la unidad.
18. Mantener contenedores, propiedades, selectores y CSS Hacks al mínimo.
19. Selectores de grupo te permiten seleccionar varios elementos de una vez.
20. Acortar la notación de colores en hexadecimal.
21. Definir las pseudoclases para enlaces en el orden LoVe/HAte.
22. Definir los márgenes, paddings y bordes de los elementos en el orden TRouBLed.
23. Puedes utilizar selectores hijos.
24. Hacer uso de diferentes tipos de medios.
25. Nombrar a las clases/IDs según su función, no su apariencia.
26. Aprender a explotar la cascada natural de CSS. CSS tiene sofisticadas reglas para la herencia de reglas.
27. Puedes usar selectores de atributos. Los selectores de atributos hacen juego con elementos basados en la presencia o valor de atributos.
28. Cambiar la capitalización con CSS.
29. Ordenar todos los elementos pertenecientes a la cabecera, contenido principal, pie de página… juntos para tener una mejor visión general.
30. Echa un vistazo a las guías de estilo de las grandes compañías.
31. Busca inspiración en los gurús del diseño.
32. Echa un vistazo a BluePrint, un framework de CSS, un montón de grandes ideas se encuentran integradas y documentadas.

Facilita tu vida

33. Usa un CSS cheat sheet.
34. Construye y prueba tus CSS en los navegadores más avanzados disponibles antes de probarlos en otros, no despues.
35. Cuando dudes, valida.
36. Prueba incrustado (embebido), lanza importado.
37. Mantén una librería de class CSS de ayuda.
38. Prueba un compresor CSS online, algunos de los métodos que emplean estos encogedores de CSS para reducir el tamaño de tu fichero CSS pueden ser empleados de una forma menos extrema para hacer tus CSS más aerodinámicos.
39. Utiliza la web devoloper toolbar de Firefox.
40. Usa un framework CSS como Blueprint.

¿Sabias que…?

41. Puedes asignar varias clases a un elemento dado.
42. Poner valores constantes a través de un documento CSS:
    • La opción más simple es sólo incluir el valor del color en cada regla que quieras y usar Buscar y Reemplazar cuando quieras cambiarlos. Esto es trivial cuando utilizas un buen editor de texto.
    • Desde que un elemento puede tener más de una clase, puedes hacer clases para cada constante o variable que quieras crear y luego asignar esas clases a los elementos (X)HTML que quieras que les afecte. Desde que un elemento puede tener más de una clase, esto no debería interferir con cualquier uso existente de atributos de la clase. Luego, si quieres cambiar el color, todo lo que necesitas es modificar la clase.
    • Usar un lenguaje del lado del servidor para rellenar el CSS.
    • Hay algunos ejemplos de lenguajes server-side de preprocesado de CSS ahora. Aparentan ser los más desarrollados.
43. Puedes añadir estilos CSS a los RSS feeds.
44. Puedes prevenir spam con CSS.
45. Puedes ofrecer diseños “customizables” dinámicamente creando ficheros CSS con PHP.
46. Hay ideas para diseño de patrones en CSS.

Como lo prometido es deuda, a continuación os muestro ciertas reglas que intento seguir cuando estoy codificando un programa. Como cada uno es de su padre y de su madre, cada programador tiene su propio estilo de codificación. Lo importante de ésto no es tener un estilo u otro, sino ser consistente con el que se tenga. Al principio siempre cuesta un poco más adaptarse a unas reglas de estilo para la codificación de un programa, pero cuando se le coge el truco las ventajas son grandes.

Estas son las reglas que sigo:

Nombrado

• Por razones de internacionalización del código, todos los nombres se derivarán de palabras en inglés. Si la palabra es compuesta se utilizarán las reglas de construcción del inglés.
• Para los nombres de funciones que realicen acciones se seguirá la regla anterior pero colocando el verbo en primer lugar (e.g. vPrintTestHeader).
• Los nombres deben ser significativos y consistentes. En especial los nombres dados dentro de una clase han de construirse con una misma lógica y siguiendo unas mismas reglas.
• En general, los nombres compuesto se escriben juntos. poniendo en mayúsculas cada nombre simple (e.g. iRoomTemperature).
• Los nombres de variables y funciones empezará siempre con un prefijo que indique el tipo al que pertenecen (e.g. iGetRoomTemperature, stMyText). En el caso de objetos, se utilizará un sufijo siguiendo al carácter "_" (e.g. myInterface_mc).
• Los nombres de los datos miembro (atributos) estarán precedidos por m_ (e.g. m_nAirPresure).
• Las constantes se escribirán siempre en mayúsculas.

Control de flujo

• No modificar el valor de la variable de control de un for dentro del bloque for.
• Todas las primitivas de control de flujo (case, do, else, for, if, switch, while...) deben estar seguidas por un bloque, aunque éste esté vacío ({}).
• Las sentencias de cada case han de terminar obligatoriamente con una sentencia de terminación como return o breal. Excepcionalmente, y en el caso de que dos o más case ejecuten las mismas acciones podrán omitirse el break pero deberá existir un comentario que lo indique.
• Todos los switch han de contener obligatoriamente una cláusula default.

Sangrado

• No se pondrá nunca más de una sentencia por línea.
• Las partes diferenciadas del programa se separan utilizando líneas en blanco o comentarios.
• Ninguna función deberia ocupar más de 80-100 líneas. En caso contrario se procurará crear funciones auxiliares, para hacer más comprensible el programa.
• Cuando una sentencia dependa jerárquicamente de otra se reflejará en el programa encolumnándola con una pulsación del tabulador más a la derecha.
• Llaves: se abrirá una llave al final de la línea que define el bloque, el cual se cerrará encolumnando la llave final con el principio de esta línea. Por ejemplo:
  Código
  C:

  1. if (a <<30) {
  2.     ...
  3. }

  Cuando existan llaves anidadas, se colocará un comentario en cada una de las llaves de cierre (}) para indicar cuál es el bloque que se cierra.

• Else: a continuación del } del if:
  Código
  C:

  1. if (a <<30) {
  2.     ...
  3. } else {
  4.     ...
  5. }

• Switch:
  Código
  C:

  1. switch (value) {
  2.     case 0: // Comentario
  3.         ...
  4.         break;
  5.     case 1: // Comentario
  6.         ...
  7.         break;
  8.     ...
  9.     default: // Comentario
  10.         ...
  11. }

Paréntesis

• Dejar un blanco entre palabra clave y paréntesis (e.g. if (a << 10) {).
• No dejar blanco entre nombre de función y paréntesis (e.g. nRepSelectPlane(plane, 0);).
• No dejar blancos entre los paréntesis y sus contenidos.

Comentarios

• Comentarios tipo javadoc. Comienzan con los caracteres "/**", se pueden prolongar a lo largo de varías líneas (que probablemente comiencen con el caracter "*") y terminan con los caracteres "*/". Se colocan siempre al principio de cada clase, al principio de cada método y antes de cada variable de clase.
• Comentarios de línea. Comienzan con los caracteres "//" y terminan con la línea. Este tipo de comentarios se usará incluso cuando el comentario ocupe varias líneas, cada una de las cuales comenzará con "//". Se utilizan normalmente al principio de fragmento de código no evidente y a lo largo de los bucles.
• Comentarios tipo C. Comienzan con los caracteres "/*", se pueden prolongar a lo largo de varias líneas y terminan con los caracteres "*/". Se utiliza para eliminar código. Ocurre a menudo que código obsoleto no queremos que desaparezca, sino mantenerlo "por si acaso". Para que no se ejecute, se comenta (en inglés se suele denominar "comment out").
• Cuando un programa se modifica, los comentarios deben modificarse al tiempo, no sea que los comentarios acaben refiriéndose a un algoritmo que ya no utilizamos.

La documentación interna de un programa incluye elementos cuyo objetivo es facilitar la inteligibilidad del mismo.

Pero, ¿qué más da que el programa pueda entenderse o no si funciona correctamente? Los programas, a veces, son estudiados y modificados por personas distintas de las que originalmente la crearon, por lo que la legibilidad de un programa es un punto importante. No es lo mismo tardar 5 minutos en entender un código que tardar un par de horas en intentar saber que es lo que hace porque no tiene unos buenos comentarios y no está correctamente estructurado. El ahorro de tiempo es increíble.

Además, la mayoría de las aplicaciones se llevan a cabo por parte de un equipo. Una buena documentación interna del código que se esté desarrollando favorece la comunicación entre los distintos miembros del equipo, mejorando su productividad. Es más, si por cualquier causa (baja, despido, etc.) hay que integrar un nuevo miembro al equipo, a éste le costará mucho menos con un código mucho más legible.

Pero una buena documentación interna no sólo va a ayudar al resto de personas a entender tu código, sino que a ti también te puede resultar beneficioso. Imagínate que hace unos meses creaste una clase en, por ejemplo, ActionScript que creaba una galería de imágenes muy guapa con un montón de efectos y transiciones que te quedo muy bien. Ahora, unos meses después, quieres modificar la clase para poder incluir una pequeña descripción a cada foto. Y no te acuerdas como lo hiciste. ¿No será más fácil “recordar” el código teniendo unos buenos comentarios y una buena estructura que tener varios cientos de líneas de código teniendo que descifrar para que se utilizan unos atributos y otros? Lo que quizás no te llevara más de media hora te puede costar una tarde entera.

Los tres elementos más significativos de la documentación interna son la elección de nombres significativos, los comentarios y la indentación. Veremos, a continuación, cada uno de ellos:

Seguir leyendo "La importancia de una buena documentación interna"