You are currently browsing the monthly archive for junio 2010.

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++.

Una decisión que afecta a todo un proyecto informático es como se organizan los ficheros en carpetas. Esto es por una parte una cuestión de gusto, pero por otra muchas veces una afectada por necesidades técnicas. Así la conclusión más importante es que no hay una forma idónea de organizar los ficheros en directorios. Sólo hay formas más o menos malas. En este artículo queremos repasar qué asuntos hay que tener en cuenta a la hora de crear las carpetas. Hay otro artículo con un ejemplo de un árbol de carpetas.

La estructura de directorios es una de las tareas iniciales de un proyecto. Conviene pensársela bien, porque cambiarla más tarde puede ser complicado. Igualmente importante son los nombres de las carpetas (y ficheros).

Es preferible usar nombres cortos, pero sobre todo significativos y comprensibles. Ficheros y carpetas cuyos nombres no contienen espacios son más fácilmente manejables por una línea de comandos y URLs. Separa palabras con guión bajo en lugar de espacios.

No utilices nombres de fichero con mayúsculas, ya que pueden causar problemas entre Unix y Linux, que distinguen entre mayúsculas y minúsculas, y Microsoft Windows que no lo distingue. Además, cualquier combinación de minúsculas o mayúsculas puede ser fácilmente convertida a sólo minúsculas (o mayúsculas). Algo útil a la hora de convertir palabras de búsqueda o argumentos de la línea de comando a ficheros.

La palabra “proyecto” se usa de forma ambigua. Un proyecto por parte de la empresa (y tu trabajo) es un conjunto de aplicaciones que debes programar. Sin embargo, cada aplicación se llama “proyecto” en tu editor, mientras el conjunto de todos estos proyectos se llama “solución” o “workspace” según el editor. Aquí usamos la palabra “proyecto” en el sentido de la empresa, es decir, tu carpeta raíz de proyecto se refiere a un workspace en tu IDE. Cada aplicación se llamará “subproyecto” o “aplicación”.

Hay muchos criterios a tener en cuenta a la hora de crear la estructura de directorios. Aquí viene una colección no completa.

  • En general es preferible tener a todos los carpetas por debajo de un directorio raíz del proyecto. Esto no siempre es posible. En sistemas Linux se distribuyen diferentes ficheros a carpetas de sistema diferentes – como “include” o “lib”. O una parte de los ficheros estará en un web host. Considera la posibilidad de mantener todos los ficheros por debajo del directorio raíz y copiarlos con un shell script a su destino final. Esto puede ser un paso de post-compilación.
  • Si  una parte de los ficheros será pública – en un web host o un API dentro  una carpeta “include”, entonces el proyecto ya debería tener esta estructura. Idealmente se podría copiar la carpeta pública al servidor host con un solo comando. Por ejemplo, todos los ficheros que estarán en el servidor web se encuentran en una carpeta “web_document_root”.
  • Separa las carpetas bajo control de versiones de las que no. No mezcles código fuente con ficheros generados. Aunque no te quedes sólo con los ficheros fuente cuando archives el proyecto. Quizá no funcionará el compilador en diez años. (Y ya verás como diez años pasan…)
  • Separa bien subproyectos para evitar dependencias. Una biblioteca podría servir para otro proyecto y debería estar claro de que más subproyectos depende.
  • Guarda bibliotecas externas en una carpeta especial. Conviene quedarse con el nombre de la biblioteca y la versión, por ejemplo “boost_1_42_0” para la versión 1.42.0 de la biblioteca Boost. Es importante saber la versión y tener la posibilidad de tener varias versiones de la biblioteca externa integradas en el proyecto. Nunca sabes cuándo adaptas tu código a la nueva versión de la biblioteca y si adaptas todo o sólo una parte. Como puede ser difícil conseguir una versión vieja, guarda las bibliotecas externas junto con tu código aunque necesites guardarla varias veces. Al precio de discos duros de hoy es más barato que pasarse un día buscando bibliotecas por ahí cuando toca un cambio en algunos años. Además, da mucha frustración deber entender un proyecto viejo y directamente no funciona o ni siquiera compila.
  • Crea una carpeta para la documentación editada y otra para la generada (por doxygen, javadoc o phpDocumentor. Ten en cuenta que la documentación generada puede crearse en varios formatos como HTML o LaTeX. Una forma de poner orden podría ser:
    • generated_doc –  La carpeta raíz de la documentación generada, contiene enlaces a la página principal index.html guardado en la carpeta “html”.
      • nombre_proyecto – El nombre del subproyecto
        • html – Un carpeta creada por la herramienta de documentación automatizada.

    De esta forma

    • Distinguimos fácilmente la documentación escrita (por un procesador de texto) de la generada.
    • Podemos, mediante enlaces a ficheros, acceder fácilmente a la documentación generada sin preocuparnos de cómo está guardada dentro de la carpeta “html”.
    • Será fácil limpiar una documentación vieja, ya que sólo necesitamos limpiar el contenido la carpeta nombre_proyecto.
  • Crea las carpetas (vacías) para los ficheros temporales que tus aplicaciones podrían generar. No guardes otra cosa ahí de forma que se pueda borrar todo su contenido sin borrar a nada importante.
  • Si una aplicación se comunica mediante ficheros, crea una carpeta entrada_mi_aplicación en que solo lee una aplicación. Así simplemente puede comprobar si hay fichero o no para procesarlo. La carpeta “salida” sería la “entrada” de otra aplicación.
  • Crea una carpeta para ficheros que sirven como base de datos, por ejemplo las imágenes subidas a un servidor web.
  • Puedes reunir las carpetas con datos temporales, de entrada y de base de datos en una carpeta de datos de aplicación. También puedes crear dentro la carpeta de cada tipo de información subcarpetas para cada aplicación.
  • Si usas una base de datos como MySQL, guarda backups en SQL junto con tu proyecto. Los ficheros que usa la base de datos en sí muchas veces no son tan fáciles a mover. Aparte de esto es probable que se comparte una base de datos entre varios proyecto y conviene no guardarla por debajo de una carpeta raíz del proyecto.
  • En tu proyecto puede tener también una carpeta para versiones viejas. Sin embargo, en este caso podría convenir crear una carpeta de proyecto nuevo.
  • Crea una carpeta para la configuración de la aplicación. Con esto nos referimos a ficheros que contienen el mismo tipo de datos, pero que se debe editar a mano para adaptarla a la plataforma o la máquina. Por ejemplo, el fichero “ip.ini” podría contener direcciones IP a usar por el programa. Es importante separar estos ficheros del programa porque la actualización del programa y la configuración de las máquinas en que corre son actividades independientes.

En fin hemos visto que son muchos los aspectos a tener en cuenta. Muchas veces es la experiencia que dice qué estructura es la que más conviene. Lo más práctico es copiar una carpeta cuando hace falta copiar algo y que esta carpeta ya contenga todo lo que será necesario. Cuando nos toca copiar varias carpetas en sitios diferentes, entonces sabemos que algo podemos hacer mejor.

Referencias

Una herramienta de control de versiones tiene un cierto potencial de adicción, ya que es difícil de dejar de usarlo cuando una vez se ha conocido sus ventajas. En este artículo queremos hablar qué ficheros conviene guardar en un control de versiones y cuando conviene no usarlo. “No usar un control de versiones” significa guardar los ficheros en el sistema de ficheros de sistema operativo, es decir en los directorios de toda la vida.

Describo en otro artículo lo que es un control de versiones. En este artículo asumo que el lector ya lo sabe.

En el artículo anteriormente mencionado defino las dos razones de usar un control de versiones, que son:

  1. Ayuda a que varios programadores pueden trabajar en paralelo.
  2. Permite mantener varias versiones de un mismo programa a la vez.

Una conclusión de esto es que no se usa un control de versiones si no se da al menos una de estas condiciones, ya que no vale la pena usar una herramienta adicional si no trae beneficio. No se pueden acceder ficheros bajo el control de versiones excepto con la misma herramienta y está puede tener problemas de compatibilidad con versiones nuevas del sistema operativo como cualquier otro programa. Tampoco es fácil añadir espacio cuando el repositorio ya ha llenado el disco duro entero. Una carpeta simple, por lo contrario, es fácilmente manejable en cualquier plataforma.

La consecuencia de no programar en paralelo es bastante obvia: un sólo programador no corre riesgo de no poder trabajar por culpa de otro. Mientras uno trabaja sólo es mucho más fácil guardar todos los ficheros en las carpetas habituales, aunque eso sí: organizando los ficheros para al menos teóricamente será fácil subirlos a un control de versiones. Nunca sabes si algún día habrá otro programador contigo.

O que habrá múltiples versiones. Mantener múltiples versiones es algo habitual en proyectos grandes. Mientras el cliente prueba una versión, los programadores ya desarrollan la próxima. Si es un software que al menos en principio cualquiera pueda descargar y usar, entonces conviene mantener el código bajo un control de versiones, ya que siempre habrá varias versiones en uso. El caso contrario es un software a medida.

Una vez entregado el software a medida al cliente funcionando, nadie se interesará por un estado intermedio durante el desarrollo. Hay una versión final y punto. Entonces se guarda esta última versión en carpetas del sistema operativo y se puede liberar el espacio en el control de versiones. Si el cliente un día quiere un cambio, se puede volver a subirlo – pero entonces a una herramienta de la última generación y no el control de versiones de hace diez años.

Si el cambio está terminado y aceptado por el cliente, entonces se vuelve a guardar la versión final en un directorio del sistema operativo. Si queremos guardar estas dos versiones, entonces podemos usar dos subcarpetas “versión 1” y “versión 2”. Personalmente prefiero usar la fecha, algo como “Versión 2010-06-01”. Así uno no se lía con los números de versiones y queda aún más claro cual es la más reciente.

En fin, guardar proyectos en carpetas simples en lugar de mantenerlos en un control de versiones puede ser una mejor solución para proyectos pequeños y con pocas versiones.

Finalmente quedan todavía dos puntos adicionales a subrayar:

  • Un control de versiones no reemplaza una copia de seguridad. Guardar su trabajo diario en un disco duro alternativo es importante para no perder datos en caso de averías.
  • Aunque el primer fin de un control de versiones es guardar las versiones de sus propios ficheros fuentes, puede convenir guardar bibliotecas externas con las fuentes, ya que una nueva versión de una biblioteca externa no está garantizada de funcionar con una versión antigua del programa. No es un error guardar todas las bibliotecas externas para cada proyecto por separado, aunque serán siempre las mismas bibliotecas. Simplemente piensa qué frustración puede ser sacar un proyecto viejo del armario y que este no compila directamente porque todavía toca buscar todas las bibliotecas por ahí y a saber con qué versión.

Por cierto, nombrar carpetas con fechas es una manera simple de organizar copias de seguridad del trabajo del día.

Referencias

Con tantas herramientas de backup, la gente se olvida muchas veces de la manera más simple de hacer copias de seguridad (si no se olvida directamente de las copias de seguridad por completo): los directorios del sistema operativo. Copias el directorio con todo su contenido, ya tienes una copia de seguridad.

Para tener aún más seguridad conviene guardar las carpetas de copia en otro disco duro o mejor aún en otro ordenador, para que su vida no dependa de la supervivencia del mismo disco que el original.

Yo uso incluso dos carpetas de backup. Uno se llama “Backup” y guarda copias enteras de carpetas. Las suelo numerar de forma secuencial, por ejemplo “Imágenes 1”, “Imágenes 2”, “Imágenes 3”, “Archivos de programas 1”. La fecha de modificación de la carpeta ayuda a saber cuál es la copia más vieja cuando hace falta liberar espacio.

Como no es tan fácil copiar la carpeta de documentos de Windows por tantos ficheros de sistemas que contiene, conviene guardar sus propios ficheros en una subcarpeta de “Mis Documentos” en que sólo tú guardas cosas (y no el ordenador). Para la carpeta “C:\Windows” siempre he preferido usar el sistema de Backup de Microsoft Windows mismo. Es una carpeta delicada y supongo Microsoft sabrá como restaurar datos ahí. El fichero que genera puedes guardar igualmente en la carpeta “Backup”. Si la marcas como comprimida, entonces tienes un dispositivo de backup rápido y comprimido.

Mi otra carpeta de copias se llama “QuickBackup“, donde guardo el trabajo del día o ficheros destinados a la papelera pero en que yo mismo quiero decidir cuando desaparezcan físicamente del disco duro. Las subcarpetas tienen nombres como “2010-06-01”. Es fácil saber de qué día son, no hace falta herramienta adicional para restaurar los ficheros y siempre sabes cuales son las carpetas más viejas a la hora de borrar copias antiguas. Normalmente borro las carpetas tras dos a cuatro meses – un tiempo en que ya no me acuerdo que guardé entonces.

Así, antes de pagar mucho por un sistema de copias de seguridad simplemente usa el disco duro de tu ordenador viejo.

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Únete a otros 57 seguidores

Archivos

junio 2010
L M X J V S D
 123456
78910111213
14151617181920
21222324252627
282930