‘Cualquiera puede escribir código que un ordenador entiende. Los buenos programadores escriben código que los humanos pueden entender’

Martin Fowler

La importancia de trabajar apoyados en una guía de estilo. El código se lee más veces de las que se escribe. A veces se puede caer en la tentación de escribir el código que simplemente funcione, sin pararnos a pensar en su legibilidad o de cuanto le costaría a alguien entenderlo sólo leyendo lo que hemos escrito. Empiezas un proyecto nuevo,  y entre función y función, clase y clase, vas cambiando de estilo y entre lo que estás escribiendo ahora mismo y lo primero que empezaste a escribir deja la sensación de que ha estado escribiendo en tu código más de una persona. O puede que tomes el proyecto que haya empezado otra persona, que no lo ha podido terminar, ves como está escrito, no te gusta su estilo y decides aplicar tu toque personal.

Con el paso del tiempo te das cuenta del error que cometiste no siguiendo una guía de estilo clara. Cuando tienes que corregir un bug que aparece en las primeras líneas de código que escribiste. O cuando tienes que entender un fragmento de código escrito por otras personas donde cada variable sigue un estilo distinto para ponerle nombre y una indentación que hace imposible saber a primera vista donde termina un bloque y empieza otro.

Precisamente, para evitar estos momentos de frustración nos gustaría dar algunas recomendaciones.

Python

Si trabajas con Python, es indispensable seguir el famoso PEP 8, la guía de estilo que se siguen las librerías estándar de Python. Además de tener siempre en mente el Zen de Python:

Python 2.7.3 (default, Sep 26 2012, 21:51:14) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

Si trabajas con Django, también es interesante echarle un ojo a su guía de estilo, que se complementa perfectamente con el PEP 8.

PHP

Si trabajas con PHP unas guías de estilo muy recomendables para seguir son los propuestos por el Framework Interop Group, y que puedes ver en estos repositorios de GitHub:

• PSR-0
• PSR-1
• PSR-2
• PSR-3

Estos documentos son inclusivos, por lo que si decides seguir el PSR-1, también deberías de cumplir el PSR-0, si decides seguir el PS2 tienes que cumplir también el PSR-1 y el PSR-0, y así sucesivamente.

Conclusión

Si empiezas un nuevos proyecto, ya sea para ti sólo o en un equipo, empieza siempre siguiendo unas guías de estilo, lo agradecerás. Lee código, es uno de los mejores consejos que puede recibir alguien para mejorar como programador, ver como escriben grandes profesionales de la industria, y que gracias al Open Source no tienes excusa para cumplir.  Y recuerda que al final, lo más importante es mantener la coherencia entre todo el código del proyecto. Si tienes que continuar un proyecto que está ya empezado, sigue las convenciones que se utilicen en éste, aunque no sean las que hubieras escogido, ya que la legibilidad siempre debe prevalecer.

Entrada original: http://www.cuble.es/la-importancia-de-seguir-una-guia-de-estilo-de-codigo/

En Cuble desarrollamos muchos tipos de aplicaciones y siempre tratamos de seleccionar la mejor herramienta para el desarrollo. Y para poder hacer eso lo mejor es tener un buen número de opciones para elegir. En este caso vamos a hablar de PyPy, una implementación de Python hecha puramente en Python. Gracias a ésto es posible realizar optimizaciones de bajo nivel que repercuten de forma significativa en el rendimiento de las aplicaciones desarrolladas en este lenguaje. En concreto, PyPy incluye un compilador just-in-time (JIT), la misma tecnología que utiliza Java y que permitió mejorar sustancialmente su rendimiento.

Además de la mejora en la velocidad de ejecución, PyPy también promete un menor consumo de memoria que la implementación más extendida de Python. CPython, permite ejecutar código no verificado en modo sandbox, además de ser compatible con las más famosas librerías de Python, como Django.

La forma más sencilla para poder hacer pruebas de este intérprete y evaluar si realmente cumple con todo lo que promete es utilizar Virtualenv. Los pasos que tenemos que seguir en Ubuntu 12.10 (x64) son:

Descargamos, descomprimimos e instalamos PyPy:

wget https://bitbucket.org/pypy/pypy/downloads/pypy-2.0-beta1-linux64-libc2.15.tar.bz2
tar xvjf pypy-2.0-beta1-linux64-libc2.15.tar.bz2
sudo mv pypy-2.0-beta1 /opt/

Creamos un entorno con Virtualenv que use este intérprete:

virtualenv -p /opt/pypy-2.0-beta1/bin/pypy pypy-env

Activamos el entorno para poder trabajar:

source pypy-env/bin/active

Y comprobamos que, efectivamente, el comando python lanza el interprete con PyPy:

A partir de aquí, ya podemos trabajar con esta implementación y comprobar si realmente se ajusta a nuestras necesidades y si es la herramienta adecuada para resolver el problema que podamos tener sobre la mesa.

Entrada original: http://www.cuble.es/pypy-implementacion-de-python-en-python/

Si usas Mercurial como sistema de control de versiones, este la versión adaptada del tip para Git que añade al prompt la rama en la que estás trabajando. Para esto basta con poner al final del fichero .bashrc o .bash_profile las siguientes líneas:

function parse_hg_branch_and_add_brackets {
hg branch 2> /dev/null | sed -e 's/\(.*\)/\ \[hg:\1\]/'
}
PS1="\u@\h:\W\[\033[0;32m\]\$(parse_hg_branch_and_add_brackets)\[\033[0m\]\$ "

Y queda algo como esto:

Si usas Eclipse en Ubuntu directamente descargado de su web en vez de instalarlo directamente desde los repositorios (recomiendo encarecidamente hacerlo con la versión que te puedes descargar) habrás notado que si usas la opción de Click derecho > “Mantener en el lanzador” en Unity, luego no puedes usar ese icono para volver a abrir la aplicación.

Para que esto no pase y se quede anclado el enlace correcto, primero tienes que crear un fichero con la extensión .desktop, por ejemplo eclipse.desktop, con este contenido:

 [Desktop Entry]
 Name=Eclipse
 Comment=Eclipse
 Exec=/path/to/eclipse
 Icon=/path/to/icon.xpm
 Terminal=false
 Type=Application

Donde /path/to es la ruta a donde tengas la carpeta de eclipse. Lo guardas, y le damos permisos de ejecución:

$ chmod +x eclipse.desktop

Ejecutamos el fichero desde nautilus, hacemos click derecho sobre el icono de Unity, y luego en “Mantener en el lanzador”. Ahora se habrá quedado anclado un icono que lanzará correctamente la aplicación.