Difference between revisions of "Main Page"
Jump to navigation
Jump to search
Jgvictores (talk | contribs) |
Jgvictores (talk | contribs) |
||
Line 10: | Line 10: | ||
** Sirve de herramienta para tratar de mantener lo técnico dentro del contexto técnico, y a centrarse la temática indicada en el asunto de la issue. | ** Sirve de herramienta para tratar de mantener lo técnico dentro del contexto técnico, y a centrarse la temática indicada en el asunto de la issue. | ||
** Da mayor visibilidad a tu duda, te puede contestar gente que no te esperarías. Esto es especialmente interesante cuando hay un desacuerdo entre dos partes: pueden intervenir terceros que aporten nuevas ideas y puntos de vista. | ** Da mayor visibilidad a tu duda, te puede contestar gente que no te esperarías. Esto es especialmente interesante cuando hay un desacuerdo entre dos partes: pueden intervenir terceros que aporten nuevas ideas y puntos de vista. | ||
+ | * La forma preferida de documentación (salvo Doxygen para C/C++) es Markdown. | ||
== Programación en General == | == Programación en General == |
Revision as of 21:38, 25 November 2016
Buenas prácticas (IMPORTANTE! LEER PRIMERO!!)
- Siempre, para cualquier archivo de trabajo, por muy insignificante o borrador que parezca, utiliza uno de los repositorios compartidos:
- Software y hardware: GitHub (GIT, público). Consulta con tu tutor (que posiblemente te redirija a Juan, David o Raúl) si dudas en qué repositorio trabajar. Acomoda tu .gitignore al tipo de proyecto, para evitar subir ficheros que no se deberían (binarios, backups, y ficheros residuales varios).
- Redacción de publicaciones: Consulta con tu tutor (que posiblemente te redirija a Juan) para la URL exacta, distribuidos a través de http://robots.uc3m.es/svn/* (SVN, privado)
- Siempre, cuando tengas una duda, busca en esta wiki, y busca entre las issues (tanto abiertas como cerradas) del repositorio asociado a tu trabajo. Si no encuentras respuesta, pon una issue en el repositorio asociado a tu trabajo (o comenta en la pestaña de Discussion de la wiki). Ventajas:
- Incrementa la productividad global, porque queda el histórico. Se tiende a evitar el estar repetiendo las mismas preguntas y generando las mismas respuestas.
- Sirve de herramienta para tratar de mantener lo técnico dentro del contexto técnico, y a centrarse la temática indicada en el asunto de la issue.
- Da mayor visibilidad a tu duda, te puede contestar gente que no te esperarías. Esto es especialmente interesante cuando hay un desacuerdo entre dos partes: pueden intervenir terceros que aporten nuevas ideas y puntos de vista.
- La forma preferida de documentación (salvo Doxygen para C/C++) es Markdown.
Programación en General
- Respeta las sangrías/indentaciones... como si todo fuese Python! ;-) PD: Existe un programa que autoajusta, que se llama astyle (utilizar con precaución!).
- NO utilizar NÚMEROS en nombres de ficheros para indicar versiones/intentos/iteraciones... ¡Para eso ya existen los hash y tag de los sistemas de control de versiones!
- NO crear DUPLICADOS de programas. Analizar en profundidad si se puede ampliar la funcionalidad de un programa a través del ajuste o incorporación de parámetros antes de crear un programa nuevo. Una vez detectado que se puede ampliar la funcionalidad de un programa, utilizar los mecanismos convencionales (issues, o fork y pull request).
- Cabeceras, ficheros de configuración y parámetros de CLI.
- Lee acerca de Clean code.
Programación C/C++
- Para crear un nuevo proyecto C/C++, utiliza project-generator.
- Si hay problema con project-generator, coméntalo en su sección de issues. Si sigues con motivos en contra, por lo menos no dejes de utilizar CMake para cualquier proyecto C/C++.
- Utiliza UpperCamelCase para nombres de librerías y de clases.
- Utiliza lowerCamelCase para nombres de ejecutables.
- Evita el uso de variables globales.
- Preferimos el uso de la clase std::string frente a alternativas como char* o yarp::os::ConstString.
- Crea tus clases dentro de un namespace.
- Mantén un main() minimalista: implementa tu programa como una clase.
- En C++ solemos hacer que la clase principal herede de yarp::os::RFModule, con lo cual se dispone de un configure(yarp::os::ResourceFinder& rf) que recibe un diccionario (rf) pasado desde el main(), un close() que se llama con la señal CRTL+C, y una función updateModule() llamada periódicamente, con una periodicidad lenta [segundos] dada por getPeriod(). Si se necesita una función que se llame rápidamente, heredando de yarp::os::RateThread se obtiene una función run() que es llamada con una periodicidad [milisegundos] especificada en el constructor.
- Si tienes un dispositivo, también impleméntalo como una clase, idealmente como un YARP device.
- Crea un test para cada clase, desarrollándolo a la par de la clase. En la actualidad utilizamos gtest, como en teo-main/test/testKdlSolver y teo-body/tests/testTechnosoftIpos.
AVISO IMPORTANTE: Al proceder, se aceptan las condiciones anteriores
Gracias!
Welcome to the Asibot & HOAP3 & TEO Wiki
| ||
---|---|---|
ASIBOT |
HOAP3 |
TEO |
AVISO IMPORTANTE |
---|
En caso de enterarte de la existencia de una DEMO, por favor ENVÍA YA email con fecha/hora y/o toda la información posible Nuestro hilo email se llama AVISO DEMOSTRACION. |
Recursos adicionales | |
---|---|
Tutorials |
Impresora pasillo |