6  Errores de programación, guías de estilo y paquetes de R

En este capítulo hablaremos sobre la posibilidad de cometer errores al programar, desde errores de sintaxis que impiden la ejecución del código hasta errores lógicos que pueden pasar desapercibidos y afectar los resultados. También destacaremos la importancia de seguir una guía de estilo para escribir código claro y fácil de depurar. Además, conoceremos el sistema de paquetes en R, una de sus características más poderosas, que permite ampliar sus funcionalidades mediante herramientas creadas por la comunidad. Aprenderemos cómo instalar y cargar paquetes para aprovechar al máximo este ecosistema.

6.1 Errores de programación

Apenas iniciemos nuestro camino en el mundo de la programación nos daremos cuenta que tendremos siempre ciertos compañeros de viaje: los errores. Muchas veces nos pasará que queremos ejecutar nuestro código y el mismo no anda o no produce el resultado esperado. No importa cuán cuidadosos seamos, ni cuánta experiencia tengamos, los errores están siempre presentes. Con el tiempo y práctica, vamos a poder identificarlos y corregirlos con mayor facilidad, pero probablemente nunca dejemos de cometerlos.

A los errores en programación se los suele llamar bugs (insecto o bicho en inglés) y el proceso de la corrección de los mismos se conoce como debugging (depuración)1. Se dice que esta terminología proviene de 1947, cuando una computadora en la Universidad de Harvard (la Mark II) dejó de funcionar y finalmente se descubrió que la causa del problema era la presencia de una polilla en un relé electromagnético de la máquina. Sin embargo, otros historiadores sostienen que el término ya se usaba desde antes.

La polilla (bug) encontrada por la científica de la computación Grace Hooper en la Mark II fue pegada con cinta en un reporte sobre el malfuncionamiento de la máquina.

La polilla (bug) encontrada por la científica de la computación Grace Hooper en la Mark II fue pegada con cinta en un reporte sobre el malfuncionamiento de la máquina.

A continuación se presenta una clasificación de los errores que se pueden cometer en programación:

  • Errores de sintaxis. Tal como el lenguaje humano, los lenguajes de programación tienen su propio vocabulario y su propia sintaxis, que es el conjunto de reglas gramaticales que establecen cómo se pueden combinar las distintas partes. Estas reglas sintácticas determinan que ciertas instrucciones están correctamente construidas, mientras que otras no. Cuando ejecutamos un programa, se chequea si el mismo es sintácticamente correcto. Si hemos violado alguna regla, por ejemplo, nos faltó una coma o nos sobra un paréntesis, mostrará un mensaje de error y debemos editar nuestro programa para corregirlo. En estos casos, hay que interpretar el mensaje de error, revisar el código y corregir el error.

  • Errores lógicos. Se presentan cuando el programa no tiene errores de sintaxis pero arroja resultados incorrectos o ningún resultado. El software no muestra mensajes de error, debido a que, por supuesto, no sabe cuál es el resultado deseado, sino que sólo se limita a hacer lo que hemos programado. En estos casos hay que revisar el programa para encontrar algún error en su lógica. Este tipo de errores suelen ser los más problemáticos. Algunas ideas para enfrentarlos incluyen volver a pensar paso por paso lo que se debería hacer para solucionar el problema y compararlo con lo que se ha programado, agregar pasos para mostrar resultados intermedios o emplear herramientas especializadas de debugging (llamadas debuggers) para explorar el código paso a paso hasta identificar el error.

  • Errores en la ejecución (runtime errors). Se presentan cuando el programa está bien escrito, sin errores lógicos ni sintácticos, pero igualmente se comporta de alguna forma incorrecta. Se dan a pesar de que el programa ande bien en el entorno de desarrollo del programador, pero no cuando algún usuario lo utiliza en algún contexto particular. Puede ser que se intente abrir un archivo que no existe, que el proceso supere la memoria disponible, que tomen lugar operaciones aritméticas no definidas como la división por cero, etc.

Los errores en la programación son tan comunes, que un científico de la computación muy reconocido, Edsger Dijkstra, dijo una vez: “si la depuración es el proceso de eliminar errores, entonces la programación es el proceso de generarlos”. Ante la presencia de uno, no hay más que respirar profundo y con paciencia revisar hasta encontrarlo y solucionarlo.

6.2 Guías de estilo

Es sumamente importante mantener la prolijidad en la escritura del código para facilitar su lectura, especialmente cuando estamos trabajando con problemas largos. Siempre hay que tener en cuenta de que cuando escribimos un programa, tenemos dos públicos potenciales: integrantes de nuestro equipo de trabajo que tienen leer el código y hacer sus propios aportes y nosotros mismos en el futuro, cuando retomemos código hecho en el pasado y necesitemos interpretar qué es lo que hicimos hacer.

Es por eso que se establecen conjuntos de reglas para controlar y unificar la forma de escribir programas, que se conocen como guía de estilo. Estas reglas cubren aspectos como, por ejemplo, la forma de escribir comentarios en el código, la utilización de espacios o renglones en blanco, el formato de los nombres para los elementos que creamos nosotros mismos (como las funciones) y para los archivos que generamos, etc. Una guía de estilo no indica la única forma de escribir código, ni siquiera la forma correcta de hacerlo, sino que establece una convención para que todos trabajen de la misma forma, basándose en costumbres que sí se ha visto que pueden tener más ventajas que otras.

Para programar en R existe una guía de estilo muy popular llamada The tidyverse style guide, creada por los desarrolladores de RStudio (Posit). En este curso vamos a adherir a sus recomendaciones. Si bien es una lectura muy interesante, particularmente si tenés intenciones de profundizar tus conocimientos sobre programación en R, no es necesario que lean dicha guía completa. Por ahora es suficiente con que imiten con atención el estilo que usamos en los ejemplos provistos en esta guía y sigan algunas recomendaciones generales como las siguientes:

  • Como dijimos antes, escribimos los nombres de nuevos objetos con snake case y en minúscula:

    • Ok: mi_objeto.
    • Evitar: MIOBJETO, miObjeto.
  • En R los espacios en blanco son ignorados, colocarlos o no no produce errores en el código. Sin embargo, se recomienda hacer uso de los mismos para facilitar la lectura. Se sugiere colocar espacios alrededor del operador de asignación <- y de los operadores matemáticos (excepto la potencia). No colocamos espacio después de abrir o antes de cerrar un paréntesis.

    • Ok: z <- (a + b)^2 / d
    • Evitar: z<-( a + b ) ^ 2/d
  • Usamos un espacio después de poner una coma y entre el signo igual que se usa para definir argumentos en una función:

    • Ok: log(100, base = 10)
    • Evitar: log(100 ,base=10)
  • Los nombres de archivo deben describir su contenido y evitar espacios, símbolos y caracteres especiales, y preferentemente estar escritos en minúsculas.

    • Ok: analisis_exploratorio.R
    • Evitar: Análisis exploratorio.R, codigo.r

Recordemos siempre que seguir un buen estilo para programar es como hacer uso de una correcta puntuación cuando escribimos, podemos entendernos sin ella, peroesmuchomasdificilleersinolarespetamosno?2

6.3 Paquetes de R

6.3.1 Diseño del sistema R

R está diseñado como un sistema modular, dividido en dos partes principales:

  • R Base: Se instala automáticamente cuando descargamos R desde CRAN (Comprehensive R Archive Network). Incluye las funciones fundamentales del lenguaje, como operadores matemáticos, herramientas para manipular datos y funciones estadísticas básicas.

  • Paquetes adicionales: Son extensiones opcionales que amplían las funcionalidades de R. Cada paquete es un conjunto de funciones y datos diseñados para tareas específicas, como visualización de datos, modelado estadístico o manipulación avanzada de estructuras de datos.

6.3.2 Instalación de paquetes

Para utilizar un paquete en R, primero debemos instalarlo. La mayoría de los paquetes están disponibles en CRAN y, teniendo conexión a internet, se pueden descargar directamente con el siguiente comando:

install.packages("nombre-del-paquete")

Esto descargará e instalará el paquete en la computadora, permitiéndolo usarlo en futuras sesiones.

6.3.3 Carga de paquetes

Después de instalar un paquete, es necesario cargarlo en la sesión de R para poder utilizar sus funciones. Es como abrirlo para sacar las funciones que están guardadas dentro. Para hacerlo, usamos la función library():

library("nombre-del-paquete")

Si intentás usar una función de un paquete sin haberlo cargado previamente, R mostrará un error indicando que el objeto no fue encontrado.

Es importante recordar que la instalación de un paquete solo se hace una vez, pero debemos cargarlo en cada nueva sesión de R en la que queramos utilizarlo. Cuando cerramos RStudio, los paquetes se descargan de la memoria, por lo que es necesario volver a llamarlos con library() la próxima vez que los necesitemos.

Este sistema modular permite que R sea altamente flexible, permitiendo a los usuarios instalar solo las herramientas que realmente necesitan para sus análisis.

6.3.4 Creación de paquetes en R

Los paquetes en R no solo son desarrollados por expertos en estadística y computación, sino también por cualquier persona que quiera compartir herramientas útiles con la comunidad. Investigadores, analistas de datos y programadores contribuyen a la expansión del ecosistema de R creando paquetes que facilitan tareas específicas.

Si bien algunos paquetes pueden ser muy sofisticados, la creación de uno no es algo exclusivo de grandes desarrolladores. De hecho, al finalizar esta materia, contarás con los conocimientos necesarios para construir tu propio paquete desde cero. Esto te permitirá organizar y compartir funciones de manera eficiente, facilitando su reutilización en distintos proyectos.

6.3.5 Paquetes utilizados en esta materia

Como estaremos aprendiendo nociones de programación, no necesitaremos usar paquetes adicionales en el contexto de esta asignatura, pero sí usarás muchos en otras materias.


  1. Algunos usan el término bug para referirse exclusivamente a errores lógicos.↩︎

  2. Frase tomada de acá.↩︎