Desde mi punto de vista Arduino/wairing (mira que soy pesado con esto) es una estupenda herramienta educativa. Una de sus principales virtudes es su simplicidad de uso y la otra es sin duda esta estupenda comunidad
Ahora bien, entiendo que una herramienta educativa adem谩s tiene la responsabilidad de inculcar buenas costumbres y es ah铆 donde me he encontrado el siguiente problema:
Mas all谩 de los primeros ejemplos los programas tienen a complicarse. El uso de librer铆as est谩 muy bien ya que reduce el tama帽o del programa cuando uso determinados dispositivos o funciones.
El problema es que cuando el c贸digo propio se complica, se generan archivos grandes. Por estructura y manejabilidad (menuda palabra) es interesante dividir el programa en ficheros independientes. Esto est谩 bien resuelto en el entorno ya que podemos ir a帽adiendo "tabs" con otros ficheros (.h o . cpp) que forman nuestra aplicaci贸n.
Ahora bien, en ocasiones varios alumnos trabajan en un mismo proyecto en el que hay involucrados varios arduinos (esto es un caso real). En dicho proyecto hay archivos de funciones o definiciones comunes. No son archivos tan est谩ticos como para crear una librer铆a con ellos ya que est谩n evolucionando a la vez que el proyecto.
La priemera idea de cara a organizare esto es poner una carpeta para el c贸digo de cada arduino y otra para el c贸digo com煤n y usar la funci贸n Sketch>>Add File.. para "a帽adirlos" en cada proyecto
El problema es que Add File hace una copia del archivo y si, por ejemplo, estamos trabajando con 4 Arduinos, podremos tener hasta 5 versiones diferentes (la de cada uno y la com煤n) de un mismo archivo.
La soluci贸n ser铆a tener la posibilidad de a帽adir dicho c贸digo de forma que lo incluya en la compilaci贸n desde su ubicaci贸n.
He visto que hay gente que pone c贸digo C/C++ en archivos .h y luego los pone como librer铆as. No creo que esta soluci贸n sea muy correcta desde el punto de vista de ense帽ar buenas t茅cnicas.
La soluci贸n ser铆a tener la posibilidad de a帽adir dicho c贸digo de forma que lo incluya en la compilaci贸n desde su ubicaci贸n.
Eso, podria ser mediante una red en la que el IDE Arduino/Wiring est茅 ubicado en un computador central, y las demas personas del grupo cambian el fichero metiendose al mismo IDE por red. Pero seria algo tedioso si estan modificando el fichero simultaneamente ya que los cambios se ven reflejados mientras se guarda el sketch y al ser un sketch de desarrollo los cambios hechos por una persona se verian complicados por el aporte del otro al momento que se guarda.
Lo digo por los avances que hace uno si otro lo guarda quedaria un contenido mixto, y quizas haga el codigo inoperable cuando lo subamos a la placa si no se abre antes y se revisa. Asi lo veo yo, aunque es una idea vaga y aplico el tema de una red simple, por ejemplo varios computadores en un mismo grupo de trabajo desde windows/linux/mac.
Lo que no hay para lo que postulo es que si estan en red, el propio IDE te valla notificando los cambios y abras el archivo nuevamente para seguir creando/corrigiendo el codigo en cuesti贸n.
Cumplubot asi lo veo, y quizas es muy descabellado lo que digo, bueno ahi puse lo que pensaba.
Igual me he expresado mal, no me estoy refiriendo al echo de que varias personas accedan simult谩neamente a una serie de archivos que est茅n involucrados en varios proyectos. Me refiero a algo ten sencillo como cuando uno separa partes comunes de un proyecto para usarlas en otro (por ejemplo, las guarda en una carpeta com煤n) y cuando las a帽adimos a nuestro proyecto Arduino copia estos archivos en vez de enlazarlos.
驴Cual es el problema?, que si uno hace 4 proyectos distintos e incluye en cada uno de ellos un archivo de funciones comunes (mediante la opci贸n de a帽adir fichero) se puede encontrar con 5 versiones distintas de un mismo fichero.
Igual es que lo estamos haciendo mal, pero a simple vista no me parece una buena forma de hacer las cosas.
Ya, ahora entiendo mejor tu pto de vista. Uhm si, eso es cierto. Yo creo que es inherente al grupo debido a que cada persona tiene su forma de reutilizar el c贸digo, es mas como plantearse una revisi贸n grupal en la que cada persona presente sus razones porq a帽adi贸 al codigo lo que hizo.
Creo q ser铆a llegar a un consenso de que el codigo beta pase a una versi贸n oficial, con partes separadas, documentas y aceptadas por todos los miembros, y no se toque mas ese codigo para luego copiarlo como carpeta a la carpeta "examples".
