Mejores prácticas para librerías de Arduino

Con todo el auge que está teniendo el movimiento Do It Yourself y la cantidad de herramientas que surgen todos los días, debo decir que me ha sorprendido bastante lo difícil que me ha resultado conseguir una librería en C o C++ que me permita trabajar en una tarjeta SD desde un micro AVR. Y me refiero a algo que integre tanto una implementación de sistema de archivos, FAT en este caso, como que utilice el protocolo SPI. Sonaría como algo muy lógico y elemental que exista algo así, o al menos a mi me lo suena. Y resulta muy desconcertante ver que no es así. Prácticamente todo lo que he encontrado está escrito para Arduino. Y eso no está bien.

Primero que nada quiero aclarar que no tengo nada en contra del Arduino, me encanta el Arduino y la flexibilidad que ofrece para prototipar rápidamente ideas tanto de hardware como de algoritmos. Aplaudo que haya una comunidad tan grande a su alrededor que lo utilice y genere nuevas librerías y shields y proyectos basados en él. Lo que me causa cierta incomodidad es el hecho de que por eso mismo, se haya estancado el desarrollo independiente de librerías más generales. Tratar de sacar de contexto una librería de Arduino y utilizarla en un proyecto en C es, en el mejor de los casos, bastante engorroso. En otros tantos es más bien imposible. Las librerías de Arduino son tan interdependientes que para utilizarlas fuera del "ambiente Arduino" uno termina copiando y editando cantidad de archivos que no tenía contemplados. Por ejemplo, para intentar utilizar la librería SD fuera del "ambiente Arduino" hay que a su vez copiar la librería SPI. Y hay que copiar los archivo Stream y Print entre muchos otros, para que al final el código no compile. Empieza entonces un largo y tedioso proceso de ir revisando y ajustando librería por librería y archivo por archivo lo cual no garantiza que al final el resultado vaya  a ser el deseado.

En la mayoría de los casos todo se debe a la utilización de "atajos." En lugar de implementar una serie de funciones necesarias para la librería que se está creando, simplemente se invoca ese mismo método de otra librería. Muy bonito de hacer, muy fácil y reduce en buena medida la cantidad de código que se debe escribir. Pero aparte de volver la librería dependiente de la presencia de otras librerías, también la vuelve vulnerable a fallar si el API de la otra librería cambia. Un remedio, más que una solución, sería que se documentase mejor esas dependencias de terceras librerías de manera que si uno quiere utilizar la librería fuera del ambiente Arduino, sepa qué funciones tendría que implementar y eso le permita tomar una decisión mucho más informada.

Resumiendo, si vas a escribir y compartir una librería:

1. Evita en la medida de lo posible tomar atajos. Escribe un código completo e independiente.
2. No asumas que el usuario final tiene tal o cual cosa. Si debe de tenerlas, házselo saber.
3. Si no escribes un código independiente, intenta utilizar librerías que a su vez no dependan de otras librerías. Documenta de qué librerías se trata, dónde se pueden conseguir y qué funciones son las que uno tendría que implementar en caso de querer generar una librería independiente.
4. Si no vas a hacer un código independiente ni a utilizar librerías independientes, de todas maneras documenta qué funciones son las que uno tendría que implementar en caso de querer generar una librería independiente. Trabajarás un poco más, no tanto como implementando las funciones, pero seguramente la cantidad de personas que usen tu librería será mucho mayor y serán mucho más felices.