Estándares de codificación

¡Bienvenidos un día más a ohmyroot! vuestro blog tecnológico favorito queridos amigos! Ya ha se han pasado las Navidades y estamos de vuelta (con un día de retraso para este post, pero bueno… ¡nadie es perfecto!). Hoy vamos a tratar un tema que aunque manido y machacado, pero que considero muy interesante y útil, hablamos de los estándares de código o codificación.

Antes de meternos en materia, quiero dar un poco de contexto a por qué considero que este es un tema muy importante, y que todo desarrollador que se precie, debe conocer como la palma de su mano. Como algunos habréis imaginado, este un humilde servidor se pasa gran parte de su día, armado con un teclado desfaciendo entuertos en el campo de la programación y los sistemas. Entre algunas de mis tareas esta la revisión formal de código y cuando no hay mas cojones remedio la refactorización, esto me lleva a preguntarme muchas veces, en que narices piensa la gente cuando se pone a programar. Sinceramente, es más común de lo que os podáis imaginar, revisar código de un test para un puesto de programador senior y descubrir que aunque en su CV es artisian PHP cum laude por la Universidad de Wichita, su código es totalmente ilegible.

estándares-de-codificación-trabajar-en-casa
Como la gente me imagina cuando trabajo desde casa.

Estándares de codificación

Para que estas cosas no pasen y tu código siempre esté a la altura, debemos seguir siempre un estándar de codificación Code Standard en inglés. Los estándares de código, son parte de las llamadas buenas practicas o mejores practicas, estas son un conjunto no formal de reglas, que han ido surgiendo en las distintas comunidades de desarrolladores con el paso del tiempo y las cuales, bien aplicadas pueden incrementar la calidad de tu código, notablemente.

Entendemos como estándar de código a un conjunto de convenciones establecidas de ante mano (denominaciones, formatos, etc.) para la escritura de código. Estos estándares varían dependiendo del lenguaje de programación elegido y ademas varían en cobertura, algunos son mas extensos que otros. Pero hay xxxx puntos que todos estándares deberían cubrir:

Comentarios.

Aunque muchas veces, a todos nos da pereza escribirlos, porque pensamos que nuestro código se explica solo, los comentarios son una parte fundamental de un buen código fuente, esto es por varias razones, entre ellas esta el explicar ese trocito de código que has condensado en 10 lineas, utilizando ternarios y diferentes funciones ayudará a un futuro tu o a un compañero que tenga que revisar tu código a entender más fácilmente lo que querías conseguir. Ademas de los comentarios para explicar determinadas partes de tu código, también es recomendable utilizar bloques de documentación en funciones, explicando parámetros, tipos esperados y lo que se persigue conseguir.

Este pequeño snnipet, es un mal ejemplo por la ausencia de comentarios, aunque yo mismo, puedo entender porque se esta haciendo eso, ya que es mi propio código, otro programador puede encontrar dificultades.

estandar-de-codificacion-vader
Esto es lo que se merecen los que no ponen comentarios.

El siguiente código, es un buen ejemplo de como ha de hacerse.

Como podemos ver contamos con un bloque de documentación y un par de comentarios, donde la funcionalidad puede no estar clara.

Convenio de denominaciones o naming conventions.

Otro de los puntos a tener en cuenta a la hora de aplicar unos buenos estándares de código, es el convenio de denominación. Estos convenios nos darán una guía clara de como debemos elegir los nombres de clases, funciones y variables. Muchos programadores suelen utilizar por comodidad nombres de variables que no tienen significado alguno ($var, int X, string palabra, etc.) y que solo hacen que entorpecer el trabajo de otros miembros del equipo o de ellos mismos cuando tienen que revisar su código después de un tiempo sin tocarlo.

El como elegir nombres, se recomienda el utilizar variables descriptivas, es decir si tenemos que almacenar el número de puertas de un coche, podríamos utilizar «puertasCoche», «NumeroPuertasCoche» «num_puertas_coche» esto dependerá de la elección personal de cada uno. Como habréis notado he utilizado en los ejemplos distintos formatos de capitalización o escritura para los nombres de la variable (he usado lowerCamelCase, CamelCase y snake_case), esto si dependerá mucho de lo que defina el estándar del lenguaje.

Legibilidad – Formato y espaciados

Por último, un buen código ha de ser fácil de leer y tener una buena estructuración visual que acompañe a la lógica del algoritmo en cuestión. A propósito de como ha de hacerse, normalmente cada estándar define una serie de reglas sobre como han de posicionarse las llaves, número de espacios a utilizar para tabular, longitud de las lineas, etc.

Lo que se busca con esto es como ya he mencionado, el hacer el código lo más sencillo de leer y de entender. Por ejemplo si comparamos estos dos bloques de código:

Nos encontramos con dos estructuras que hacen exactamente lo mismo, pero que la forma de representarlo es radicalmente diferente. Acerca de esto podemos encontrar versiones y argumentos para defender o atacar ambas. Como ventajas del primer bloque vemos que el leerlo es mucho mas sencillo y se entiende en un vistazo, pero como contra ocupa 8 lineas, comparado con el segundo que solo ocupa una, en el caso de encontrarnos con un proyecto con una gran cantidad de lineas, la segunda opción sería mucho mas aceptable, porque nos ahorraría esfuerzo a la hora de buscar entre el código, pero la primera en un proyecto con un tamaño más modesto facilita el entender el código. En este caso al final es también una decisión personal de cada programador u equipo de programadores.

Lo importante acerca de estas normas es que una vez decididas cuales se van a seguir, estas se cumplan a rajatabla y que no se alteren en mitad del proyecto.

Lista de diferentes estándares de código.

  • http://www.php-fig.org/psr/ (Consultar 1 & 2)
  • https://msdn.microsoft.com/en-us/library/ff926074.aspx
  • https://google.github.io/styleguide/javascriptguide.xml
  • https://www.python.org/dev/peps/pep-0008/
  • https://google.github.io/styleguide/cppguide.html
  • https://wiki.haskell.org/Programming_guidelines#File_Format

Y con esto terminamos este post, que espero que os sirva de ayuda y los que todavía no lo seáis, empecéis a ser firmes creyentes de los estándares de código. Nos vemos en el próximo rootie!

Para cualquier duda, pregunta, comentario, soborno o amenaza, podéis usar los comentarios o en nuestras redes sociales Facebook y Twitter.

 

One Comment

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *