Errores comunes que cometemos cuando aprendemos a programar
Te contamos cuáles son los errores más comunes cuando empezamos a programar y cómo hacer para evitarlos.
1. No entender cuál es el problema
Decimos que programar es el arte de solucionar problemas con la ayuda de una computadora. Por lo tanto, una parte clave de programar es entender bien cuál es el problema que queremos solucionar.
Antes de empezar a escribir nuestro código tenemos que entender cuál es objetivo del mismo. Para eso sirve preguntarnos con qué información contamos y qué información queremos obtener.
Un error muy común es devolver un tipo de dato distinto al que se nos pide. Antes de empezar a escribir el código intentemos entender los tipos de datos de entrada y de salida. Por ejemplo, supongamos que tenemos que definir una función llamada esNumeroPar que recibe un número y nos dice si es par o no. En este caso, el argumento que recibe como parámetro será un número, ese será nuestro tipo de dato de entrada. Y lo que se nos pide es que esa función nos diga si es verdadero o falso que ese número sea par, por lo tanto el tipo de dato que devuelva nuestra función deberá ser un booleano (verdadero o falso).
Si estás aprendiendo en la Plataforma Mumuki, para entender bien el objetivo del código solicitado es importante leer con atención la consigna que aparece en un recuadro celeste.
2. Escribir el código sin pensar la solución
Cuando empezamos a programar tendemos a zambullirnos directamente en la escritura del código, y ese es un error. Una vez que ya entendimos cuál es el problema, es decir, que ya sabemos qué tenemos que hacer, tenemos que pensar cómo hacerlo. Antes de empezar a escribir el código, tenemos que pensar cómo tiene que ser.
Para eso sirve preguntarnos cuál es el conjunto de herramientas que podrían sernos útiles. ¿Qué lenguaje me conviene para resolver este problema? ¿Este lenguaje nos da alguna función que podamos utilizar? ¿Hemos creado alguna función o procedimiento anteriormente que podamos reutilizar? ¿Podemos dividir el problema en problemas más pequeños?
Para pensar la solución sirve mucho recurrir a nuestros viejos y conocidos lápiz y papel. Podemos anotar cuáles son, a grandes rasgos, las tareas que debemos solucionar, y qué herramientas pueden funcionarnos. También es útil primero plantear la solución en pseudocódigo, y luego traducirla a la sintaxis del lenguaje que elegimos.
Si estás aprendiendo en la Plataforma Mumuki, para entender cómo plantear la solución es importante leer la pista, ya que allí muchas veces aparecen herramientas que podemos usar en el código para solucionar el problema.
3. No indentar el código
Indentación, o identación, es un anglicismo de la palabra inglesa indentation. Si bien la palabra te puede sonar extraña, hace referencia a la sangría, es decir, al espacio que dejamos entre el margen izquierdo y el comienzo de un texto.
Indentar es súper importante a la hora de programar, por dos razones:
1. En cualquier lenguaje, indentar nuestro código sirve para que se pueda leer y entender más fácilmente. Permite visualizar la jerarquía entre los componentes de la solución, es decir, qué cosa está dentro de otra.
2. En algunos lenguajes la indentación es una condición necesaria para que funcione nuestro código, como Python o Haskell. Decimos que estos lenguajes son “indentation sensitives” ya que si no tabulamos de manera correcta, no se procesará nuestro código.
Si estás aprendiendo en la Plataforma Mumuki, para aprender a indentar correctamente, te recomendamos copiar la forma en la que está escrito el código en los ejemplos, respetando la tabulación.
En este ejemplo vemos el mismo código en Python, a la izquierda sin indentar y a la derecha indentado. Cuando el código está sin indentar la solución no se puede ejecutar.
4. Elegir malos nombres
Las series y películas suelen mostrar a las personas que programan como hackers que escriben un código totalmente incomprensible e indescifrable. ¡Qué representación equivocada! Nada más lejos de la realidad. La programación no tiene que estar encriptada ni ser difícil de descifrar, más bien, todo lo contrario. El código que escribimos tiene que ser legible y entendible.
Por eso es fundamental elegir buenos nombres para nuestras funciones, procedimientos y parámetros. No hay que abreviar, ni intentar ahorrar caracteres. Ahorrar tiempo al escribir nuestro código sólo nos va a hacer perder tiempo cuando intentemos leerlo en un futuro.
Pensemos en conjunto con un ejemplo. ¿Qué nombre le pondrías a una función que nos dice si una persona es mayor de edad?
-mDeE
-mayor
-esMayor
-mayorDeEdad
-esMayorDeEdad
¿M de E? ¿Mes de Enero? ¿Milanesa de Espinaca? Como ya dijimos, nunca tenemos que abreviar, sólo generará más confusión.
Si nos encontramos con una función llamada simplemente “mayor” podríamos pensar que recibe un número y devuelve un número mayor, y no es lo que buscamos en este caso.
La opción “esMayor”, al estar formulada como la pregunta (“¿es mayor?”) nos da una pista de que debería devolver una respuesta a esa formulación: Verdadero o Falso, es decir, un booleano. Sin embargo, que algo sea mayor a otra cosa no siempre se relaciona con la mayoría de edad, por ejemplo, el número 10 es mayor al número 5.
Teniendo en cuenta estos indicios podríamos decir que la mejor opción para una función que nos dice si una persona es mayor de edad es el nombre “esMayorDeEdad”: al estar formulada como una pregunta intuimos que devuelve un booleano y que dicho booleano nos dirá si alguien alcanzó o superó la mayoría de edad.
5. No revisar la sintaxis
La sintaxis es el conjunto de reglas o convenciones que establece cómo tiene que estar escrito nuestro código en un determinado lenguaje. Imaginate que te llega un mensaje por Whatsapp que dice “hola como estas”. Aunque no tenga mayúsculas, tildes, ni signos de interrogación podemos entender el significado del mensaje. Pero con la computadora, eso no sucede. Si no escribimos tal cual como la compu lo espera, no va a entenderlo.
Muchas veces la solución que planteamos en nuestro código y los distintos pasos de nuestro algoritmo son correctos y, sin embargo, el programa no funciona por un paréntesis de más o una llave de menos. Por eso, si ya repasaste mil veces la lógica de tu código y no entendés por qué no funciona, no desesperes, revisá detenidamente la sintaxis.
Si bien la sintaxis varía según el lenguaje de programación que usemos, acá van algunos consejos generales:
- Por cada caracter que abre, como un paréntesis “(“ o una llave “{“, tiene que haber otro que cierre.
- No da lo mismo escribir con mayúscula o con minúscula.
- En algunos lenguajes, como ya contamos, los espacios y la tabulación son condición necesaria.
- En otros lenguajes, no debemos olvidar cerrar cada sentencia con un punto y coma.
6. No prestar atención a la ortografía y el tipeo
Son los errores que cometemos cuando escribimos con un teclado, como apretar la tecla incorrecta, omitir presionarla o hacerlo en un orden equivocado. Al igual que sucede con la sintaxis, cuando hablamos con otra persona los errores de ortografía o tipeo no suelen dificultar la comunicación. Peeero cuando programamos una letra de más o de menos puede hacer que todo nuestro código falle.
A veces nuestro código no funciona porque escribimos “lenght” en vez de “length”, o “procedire” en lugar de “procedure”. Por eso, además de corroborar la sintaxis, es importante revisar que todas las palabras estén escritas correctamente.
7. No probar nuestro código
Siempre que construimos algo tenemos que probar que funcione. Pensemos en un auto. No basta con que se mueva. Antes de salir de la fábrica tienen que probar que el airbag se abra, que los neumáticos soporten la carga y que los frenos funcionen, por nombrar algunos casos.
Con la programación es lo mismo. Tenemos que asegurarnos que nuestro código solucione el problema pero también es fundamental que probemos qué sucede con distintos casos.
Volvamos al ejemplo de la función esMayorDeEdad, ¿qué casos podríamos probar?
- Alguien de más de 18 años. Si probamos, por ejemplo, el caso de una persona de 54 años, ¿nos dice que efectivamente es mayor de edad? ¿Y una de 19?
- Alguien de menos de 18 años. Si probamos el caso de una persona de 13 años nos debería decir que es falso que sea mayor de edad.
- Alguien de 18 años. ¿Qué pasa con nuestra función esMayorDeEdad si la probamos con alguien de 18 años? Si la escribimos correctamente, nos debe decir que es mayor de edad. Es decir, no es mayor de edad quien tiene más de 18 (edad > 18), sino quien tiene 18 o más (edad >= 18).
- Números negativos o que no sean enteros. ¿Y si por error alguien prueba un número negativo? ¿Cómo funciona nuestra función si recibe como parámetro -4? ¿Y si la probamos con 12,99?
8. No leer el error
Nunca queremos equivocarnos pero, si lo hacemos, vamos a querer entender qué estamos haciendo mal. Cuando programamos por fuera de Mumuki, ya sea en la consola o en el test que estamos haciendo, nos aparecerá un mensaje de error cuando el código no funciona.
Los mensajes de error son necesarios. Imaginemos que queremos hacer 8 dividido 0. ¿Qué te gustaría que devuelva esa función? No queremos que nos diga 8 ni 0 ni cualquier otro número, sería mucho más útil que nos diga “no se puede dividir por cero”.
Estos mensajes nos dan información para poder corregir nuestro código. Por lo tanto, no leer el error es un gran error.
A veces los mensajes de error no son muy amigables para su lectura, en ese caso te recomendamos googlearlo. ¡Seguramente alguien ya se encontró con ese error antes que vos!
Si estás aprendiendo en Mumuki, cuando un ejercicio te queda en rojo o amarillo te va a aprecer un mensaje de error donde te vamos a indicar, con un lenguaje lo más simplificado posible, por qué fallaron las pruebas. Por ejemplo:
Se esperaba un paréntesis izquierdo (“(“). Se encontró: un identificador con minúsculas.La solución parece tener un error de tipeo: debe usar PonerDiagonal, pero usa PonerDiagomal. ¿Quizás quisiste decir PonerDiagonal?
