Cuando somos pequeños y estamos empezando a escribir es importante seguir unas pautas para que todo el mundo entienda nuestra letra. Decir “¡pero si yo lo entiendo claramente!” no sirve de nada.

Siguiendo este símil, a la hora de escribir código es de suma importancia hacerlo de forma clara, concisa y, ante todo, legible. En este post veremos qué es un Code Style, qué debería contener y por qué es tan importante a la hora de escribir código con buena letra.

¿Qué es el code style?

Podríamos decir que es el cuadernillo Rubio de los desarrolladores. Se trata de un documento que reúne una serie de guías o pautas a seguir tanto en la estructura del código como en la forma de implementarlo.

¿Por qué es tan necesario?

Por norma general, en todos los equipos hay bastantes programadores, cada uno de su madre y de su padre, con sus manías o costumbres. Debido a esto, llegar a un consenso puede ser una batalla campal en los inicios pero, nos guste o no, tenemos que llegar a un acuerdo.

Lo importante de un buen Code Style es que no venga impuesto por nadie y se llegue a una correcta definición entre todas las personas del equipo. Además, estará siempre sujeto a cambios y actualizaciones. Es muy importante que se escuchen todas las propuestas y se lleven a foro para evaluarlas y estudiar su posible cabida. De esta forma, todos nos sentimos parte de él y lo acataremos sin problemas.

¿Quién debe seguirlo?

Todo el mundo, sin excepciones. No hay excusas para aplicar el Code Style en todos los proyectos. Ni por las prisas, presiones, ni nada por el estilo; el código debe ser claro siempre. De esta forma si alguien nuevo llega a nuestro proyecto, sus tareas no se convertirán en una muerte a pellizcos y evitaremos que sea casi imposible cualquier modificación en el código.

¿Qué debería contener?

A grandes rasgos, en las secciones de nuestro Code Style incluiremos:

Nomeclatura utilizada

Establecemos pautas para la definición de nombre de:

• Ids. Cuanta más información demos, mejor. Ej: login__input__username
• Clases e interfaces. Comenzar por mayúsculas, usar camel case, tener un nombre descriptivo y especificar a qué hace referencia la clase. Ej: LoginFragment, LoginActivity, etc.
• Variables. Tienen que ser autodescriptivas (nada de aux1, aux2, etc.). Proporcionaremos además información adicional sobre su accesibilidad. Ej: private String mTriesToFOrceCloseApp
• Métodos. Al igual que las variables, serán autodescriptivos y comenzarán siempre por un verbo. Ej: clickOnAcceptBtn()

Definición de bloques funcionales

Es importante la distinción de bloques funcionales simplemente con un primer vistazo a nuestro código, evitando que todo el código esté apelotonado, complicando así su lectura y comprensión.

• Try/catch. Los bloques catch nunca estarán vacíos y respetaremos tanto los saltos de línea como los espaciados.

  try { ejecutaUnMetodo(); } catch (MyException e) { Log.e("MyTag", "Esto es un pete capturado"); }

• Switch. Separaremos los distintos case con un salto de línea si llevan un break para separar bloques funcionales. Para los case que tienen código pero no tengan un break, incluiremos una anotación para indicar que la ejecución sigue en el siguiente case.

  switch(entrada) { case 1: case 2: ejecutaMetodoUno(); /* falls through */ case 3: ejecutaMetodoDos(); break; default: ejecutaCasoPorDefecto(); }

• Bucles. Respetaremos los espaciados y diferencias de bloques funcionales.

  while (condicion) { //- Código... }

Buenas prácticas

Ni que decir tiene que hay que seguir una serie de pautas para que nuestro proyecto cumpla los estándares de calidad y pueda pasar herramientas como SonarQube sin ningún tipo de problemas.

• Saltos de línea. Es importante no abusar de los saltos de líneas y ponerlos siempre siguiendo unas pautas. Ej: En los patrones Builder después del operador “.”, en las condiciones después de “&&” o “||”, etc.
• Uso de this. Lo usaremos sólo para salvar ambigüedades.

  public class A {
      private String mName;
      public boolean selected;   
   
   
      A (String name, Boolean selected) {
          mName = name;
          this.selected = selected;
      }
   
   
      public void setSelected(boolean selected) {
          this.selected = selected;
      }
  }

Tratamiento de excepciones o flujos incoherentes

Nuestro código tiene que ser seguro, por ello, debemos controlar todas las excepciones y tener una app libre de crashes. Además debemos seguir una nomenclatura para el reporte de las excepciones cuando se usan herramientas de log de crashes, de esta forma serán más fáciles de solventar.

¿Nuestro código necesita comentarios?

En principio no, ya que los nombres de los métodos y variables serán autodescriptivos. Además los métodos serán atómicos, consiguiendo que cada función haga una única tarea y pudiendo así entender qué se está haciendo y por qué con un primer vistazo. No obstante, podemos añadir comentarios para aclarar ciertas partes del código vinculados a la lógica de negocio con el fin de facilitar su comprensión.

Ejemplo de uso

A continuación vamos a ver un ejemplo muy simple de su aplicación: Antes de aplicar Code Style:

//- Código aglutinado y de difícil lectura
if(condicionA&&condicionB&&(condicionC||condicionD))
   //- Código

Después de aplicar Code Style:

boolean condicionE = condicionC ||
                        condicionD;
                        
    //- Correcto espaciado y salto de líneas
    if (condicionA &&
            condicionB &&
            condicionE) {
        //- Código
    }

En resumen, aunque en un principio pueda parecer un engorro consensuar o llegar a un acuerdo sobre su uso, gracias al Code Style escribiremos un código que simplificará tanto nuestro trabajo como el de nuestros compañeros.

Android Team
ALTEN