Lo he decidido: voy a dedicar un rato todos los días a aprender a programar en AS3. Hace ya un año que empecé con ActionScript 2 y creo que ahora es el momento de dar un paso más y empezar a utilizar la nueva versión del lenguaje. Por lo poco que he visto, esta nueva versión se asemeja todavía más a Java y, dada la mayor experiencia que tenga en este lenguaje, no creo que sea muy difícil adaptarme a AS3 XD

Ya postearé por aquí mis andanzas

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.

Hoy me he decidido a participar en un concurso de posicionamiento que se realizará este verano (verano aquí en España XD ) patrocinado por los Hoteles Magic Costa Blanca. El concurso comienza hoy 10 de julio y se desarrollará hasta el 5 de septiembre, cuando se sabrán los ganadores.

Mi intención de participar no es ganar, puesto que se que es muy complicado aparecer en los primeros puestos, pero bueno, al menos aprenderé un poco más de posicionamiento web

Y si hay suerte, puede que consiga alguno de los premios que son, entre ellos, vacaciones en un hotel del sponsor en Benidorm, un IPhone y para el tercero un Apple TV.

Pues bueno, la palabra a clave que hay que posicionar en el concurso es hoteldipity. A ver que tal sale y si podemos conseguir gratis un IPhone XD

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"

Hace tiempo que no actualizaba el blog. Esto se debe a que he estado un poco liado estas 2 semanas anteriores.

Una de las cosas que me ha ocupado el tiempo ha sido la creación de mi página web personal. Se trata de una página sencilla desarrollada en flash y con php como lenguaje de servidor para los datos dinámicos (como el portafolio) y el formulario de contacto.

Esta página es la primera que realizo en flash. La programación y el diseño están casi finalizados, tan sólo me queda rellenarla de contenido (texto y proyectos).

Si podéis, echarle un vistazo y me la criticáis para poder mejorarla

La versión beta de Apollo ya está disponible en los laboratorios de Adobe. Uno de los cambios significativos ha sido la transformación del nombre. Apollo era el nombre que se le dió durante el desarrollo y ahora, en el lanzamiento de la beta con toda la funcionalidad completa de la herramienta, se le da el nombre de Adobe Integrated Runtime (o Adobe AIR para los amigos ). La verdad que a mí me gustaba mucho más el nombre de Apollo

Se va a hablar mucho en estos días sobre el lanzamiento. Podéis ver la página oficial de AIR en los laboratorios de Adobe, las "release notes", la documentación de la Beta 1 y el foro oficial de AIR en Adobe.

PD: Además, también se encuentra disponible la beta de Flex. Muchas novedades de golpe asi que a trabajar

Además de los básicos AND, OR y cadenas entrecomilladas, Google ofrece una sintaxis especial para poder mejorar y ajustar nuestras búsquedas.

Siendo Google un motor de búsqueda full-text, indexa las páginas web enteras en lugar de sólo títulos y descripciones. Comandos adicionales, llamados sintaxis especiales, permite a los usuarios de Google buscar partes específicas de las páginas web o tipos específicos de información. Esto resulta útil cuando te encuentras con dos mil millones de páginas y necesitas cualquier ayuda que pueda reducir los resultados de la búsqueda. Especificando que las palabras buscadas sólo aparezcan en el título o la URL de una página web devuelta es una gran manera de tener unos resultados más específicos sin tener que hacer que tus palabras de búsqueda sean más específicas.

Seguir leyendo "Sintaxis especiales al buscar en Google"

Una expresión regular (regex o regexp) es una cadena de texto especial para describir un patrón de búsqueda. Puedes pensar en las expresiones regulares como si fueran los comodines de los asteriscos. Seguramente que estás familiarizado con la notación *.txt para encontrar todos los ficheros de texto. La expresión regular equivalente sería .*\.txt.

Pero puedes hacer mucho más con las expresiones regulares. Por ejemplo, con:
([a-z]+)\.([a-z]+)\.([a-z]+)
coinciden www.davidvalverde.com, blog.misitio.es, etc. Los caracteres especiales que se utilizan con las expresiones regulares reciben el nombre de metacaracteres. Los que aparecen a continuación son los más usados:

Seguir leyendo "Expresiones regulares"