These are chat archives for LidiaSanchez/Normativa

5th
Dec 2015
aliciasancp
@aliciasancp
Dec 05 2015 13:13
Creo que igual es más cómodo Drive pero como queráis. Y en cuanto a la documentar los métodos creo que el método de Cristina es el mejor, también si se cree que alguna parte del método puede ser liosa también se puede comentar.
Cristina Blanco
@CristinaBlanco
Dec 05 2015 13:20
Dadme vuestros correos y os paso eso
Cristina Blanco
@CristinaBlanco
Dec 05 2015 13:49
Os podría poner el enlace pero creo que mejor tener todos una carpeta compartida para que todos veamos el trabajo de todos, no solo yo. Al no ser que Lidia nos pueda habilitar algo en ágora, utilizamos Google Drive.
Rober de Castro
@roberdcr
Dec 05 2015 15:16
Yo uso Dropbox, si vamos a utilizar github se sube todo al repositorio y listo
aliciasancp
@aliciasancp
Dec 05 2015 15:25
Cierto se sube a git
Iván de Paz Centeno
@ipazc
Dec 05 2015 16:08
Coloca en el directorio raíz del proyecto la documentación que estimes oportuna. Por convenio se utiliza un formato de texto fácilmente interpretable desde el navegador, como por ejemplo un fichero de texto sin formato o basado en MD MarkDown
Iván de Paz Centeno
@ipazc
Dec 05 2015 16:22

Respecto a la guía de estilo, propongo ordenar las definiciones de funciones por orden de lectura, de forma que siempre sea de arriba hacia abajo. Es decir, si una función llamada hola() utiliza la función decir() y la función salir(), el orden de presentación en el código sería:

void hola() { ... }
void decir() { ...}
void salir() { ... }

También propongo no colocar en el código ni autores ni fechas (excepto en aquellos casos en los que se referencie trabajo de otros), porque el git nos lo hace automáticamente en cada commit y push.

Respecto a la identación, propongo el uso de 4 espacios en lugar de tabulaciones, formato UTF-8 y seguir el estilo K&R .

Iván de Paz Centeno
@ipazc
Dec 05 2015 16:30

Sobre el formato de comentarios, propongo seguir un esquema tipo javadoc:

/**
 * prints a message.
 * 
 * @param text  text to show.
 * @return 1 if success, 0 otherwise.
 */
int say(char * text)
{
  // And inline comments should be like this one.
   ...
}

Y por último, ¿qué opináis de generar el código y la documentación del código íntegramente en inglés? yo estoy a favor de usar inglés.

Cristina Blanco
@CristinaBlanco
Dec 05 2015 17:10
En cuanto a lo de las funciones me parece bien. Lo de autores y fechas yo lo daba por supuesto pero está bien indicarlo por si acaso. En cuanto a la identación, a mi, personalmente no me gusta ese estilo (yo soy más de poner todas las llaves jaja) pero no me importa adaptarme, no supone un gran esfuerzo tampoco, así que ese punto me da igual. En cuanto a javadoc, me refería a ese formato en mis anteriores comentarios pero bueno, yo creo que entre los que escribimos aquí, lo que diga la mayoría.
Por cierto, he ido escribiendo la wiki. Si veis algo que no os guste decidmelo.
Y lo del inglés... prefiero español ya que el código secuencial tiene los comentarios en español, variables en español, funciones también, etc... si nosotros lo hacemos en inglés tendremos el código con los dos idiomas y me parece un poco "cutre" y tampoco nos vamos a poner a traducir todo.. así que opto por español.
Cristina Blanco
@CristinaBlanco
Dec 05 2015 17:47
en cuanto a lo que comentas Iván de usar un formato fácilmente interpretable por el navegador... no lo veo necesario, puede ser un .docx perfectamente, o versión openOffice, es que simplemente es un documento que me tenéis que entregar cuando acabéis de paralelizar para poder hacer la documentación final. No hay ni que actualizarlo en el repositorio y es algo que ni se va a entregar, simplemente es para facilitar la doc
también lo digo porque incluye tablas que son mucho más difíciles de hacer en el formato que comentas
Rober de Castro
@roberdcr
Dec 05 2015 19:00
Yo también estoy a favor de utilizar inglés para todo el código