Ya sea un “}” o un “;” Lo más frustrante en la vida de un desarrollador es hacer que un código compile, sobre todo cuando se ha copiado alguna parte del código desde StackOverflow, Github o algún blog o foro, al buscar ayuda para implementar alguno de los requerimentos del cliente.
Los errores principales al copiar código (más allá de los símbolos como }) pueden ser devastadores, a tal grado que el proyecto completo deje de compilar, sin embargo muchas veces es inevitable implementar algún componente, biblioteca (librería) o algún otro segmento de código, por lo tanto aquí les daré algunos tips para evitar éste tipo de errores en el desarrollo.
Errores de sintaxis: {} ;
Los errores de sintaxis son lo primero que viene a la mente del desarrollador cuando un código no compila, y en cierto modo es la realidad. La primer línea de defensa al copiar código para evitar tales tipos de errores se puede resumir de la siguiente forma.
Verificar sintaxis de flujo {}
Más del 50% de los errores de un código copiado es error en el flujo, faltan braces (corchetes), punto y coma, paréntesis (), etc. Es muy importante verificar que cada vez que se abra un método o función con un corchete {, debe cerrarse }. Algunos de los errores más comunes de sintaxis, son los siguientes:
{} -> Inicio y fin de función, Ejemplo: fun codigo{ Algo }
[] -> Inicio y fin de longitud de array, Ejemplo: var miArray[44];
; -> Fin de línea (Algunos de lenguajes, obligatorio en algunos lenguajes como Java o C).
() -> Parámetros de una función, también puede significar el contenido de una función asíncrona (en algunos lenguajes).
Recuerda, la regla es todo lo que se abre, se tiene que cerrar en el mismo orden. Muchos de éstos errores tienen que ver con el orden de cerrado. Al copiar código (y sobre todo de muchos lados) ten cuidado de no pegar código así: {{({ )}}}.
Errores de declaración de variables
Siempre habrá falta declarar variables nuevas e incluso implementar bibliotecas no mostradas por el autor de la ayuda en StackOverflow. En Android Studio basta dar click sobre la variable no declarada y poner Alt+Enter para ver las posibles bibliotecas que hace falta implementar para proporcionar la clase que hace falta para que funcione la variable.
Errores de inicialización de variables
Si intentamos utilizar variables sin inicializar, en algunos lenguajes de programación como C++ truena la aplicación, en otros adquiere null. En Kotlin se puede utilizar la directiva lateinit para indicar que la inicialización se realizará más adelante, por ejemplo declarando dentro de una clase e implementando dentro de uno de sus métodos.
Errores de tipo (cast)
Convertir variables de un tipo a otro suele ser delicado, en los lenguajes de programación más antiguos como C, podría ocasionar errores en tiempo de ejecución. En lenguajes como Java se deben utilizar los métodos predefinidos para ello, por ejemplo String.valueOf(variable) o variable.toString()
Null pointer exception – Null no detectados
Éstos son los errores más escondidos que existen, no avisan cuándo van a aparecer y muchas veces son difíciles de replicar, ya que aparecen generalmente en tiempo de ejecución: Null pointer exception y truena la app.
Es muy importante al desarrollar aplicaciones utilizar el modo debug para rastrear los valores de nuestra aplicación. En lenguajes antiguos no había de otra más que llenar de print toda la aplicación para rastrear los valores adquiridos por las variables y así detectar los null.
Toda implementación en un branch independiente
Es algo muy ignorado y muy fácil de hacer. Si mantenemos el versionamiento de código con Git, ya sea en forma privada o en colaboración, podremos hacer cada nueva implementación en un branch independiente y así tener la posibilidad de dar roll back en caso de regarla al copiar algún código.
Si el proyecto es personal, tal vez sea suficiente hacer respaldos de cada nueva implementación, sin embargo es más sencillo dejar esa tarea a un gestor de código como Git.
No utilizar patrones de diseño
Salvo que sea un desarrollo muy sencillo, el no utilizar los patrones de diseño, por ejemplo MVC, MVVM, MVP, entre otros, desorganiza la estructura del proyecto desde el principio, complicando el desarrollo de un proyecto colaborativo y hasta puede hacer que el desarrollador se vea tentado a utilizar las peores prácticas como el código spaguetti.
No documentar
Fatal para proyectos no escolares, y sobre todo cuando el código lo tienes desorganizado, peor si estás en un ambiente de colaboración. Debes procurar documentar código al menos clases y métodos para facilitar la tarea de entendimiento por parte de los otros miembros del equipo.