Contribuciones a &arts; Cómo puede ayudar El proyecto &arts; admite la ayuda de muchos desarrolladores para hacer que las aplicaciones multimedia existentes le soporten, para escribir nuevas aplicaciones multimedia, y para mejorar el propio &arts;. Sin embargo, no es necesario ser programador para colaborar. También se necesita ayuda de gente que haga pruebas de funcionamiento y envíe informes de fallos, traductores que adapten las aplicaciones y la documentación a otros idiomas, artistas que diseñen dibujos (especialmente para los módulos de artsbuilder), músicos que escriban módulos de ejemplo, y escritores que redacten la documentación. Listas de correo La mayoría de las discusiones sobre el desarrollo de &arts; tienen lugar en dos listas de correo. Es el lugar para tratar nuevas características e ideas de implementaciones o para pedir ayuda ante los problemas. La lista de correo Multimedia de &kde; trata temas generales de multimedia en &kde; así como aplicaciones multimedia como &noatun; y &aktion;. Puede suscribirse desde la página web http://www.kde.org/mailinglists.html o enviar un correo electrónico con el asunto subscribe su-dirección-de-correo a kde-multimedia-request@kde.org. La lista está guardada en http://lists.kde.org. La lista de correo de &arts; trata temas específicos de &arts;, incluyendo el uso de &arts; externo a &kde;. Para suscribirse, envíe un correo electrónico que contenga en el cuerpo del mensaje subscribe su-dirección-de-correo a arts-request@space.twc.de. La lista está guarda en http://space.twc.de/~stefan/arts-archive. Estándares de programación Para conseguir una lectura consistente de los códigos fuente, es importante mantener el mismo estilo de programación en todo el código de &arts;. Por favor, aunque escriba símplemente un módulo, trate de escribir y dar formato a su código fuente de acuerdo al estándar, así será más sencillo que otras personas mantegan esos archivos, y más fácil copiar porciones de un código a otro. Nombres de las funciones miembro Estilo &Qt;/&Java;. Eso significa utilizar mayúsculas en los cambios de palabra, la primera letra en minúsculas y sin caracteres de subrayado. Esto significa por ejemplo: crearDescripcionEstructura() actualizarElemento(); iniciar(); Miembros de clases Los miembros de clases está en minúsculas, como 'barramenu' o 'boton'. Cuando haya funciones de acceso, el estándar debe ser al estilo de &MCOP;, es decir, cuando haya un miembro largo foo, que no debe ser visible directamente, escriba funciones: foo(long nuevo_valor); long foo(); para leer y establecer el valor. En ese caso, el valor real de foo debería quedar almacenado en _foo. Nombres de clases Todas las clases deben comenzar con cada palabra en mayúsculas, como en ModuloVer, ModuloSintesis. Todas las clases que pertenezca a bibliotecas deben utilizar el espacio de nombres de &arts; como Arts::Servidorsonido. Las implementaciones de las clases &MCOP; deben ser llamadas Clase_impl, como ServidorSonido_impl. Parámetros Los parámetros van siempre en minúsculas. Variables locales La variables locales van siempre en minúsculas, y pueden tener nombres como i, p, x, &etc; según lo apropiado que sea. Tabulación Un tabulador tiene una longitud de 4 espacios. Espacios en expresiones Normalmente no es necesario utilizar espacios en expresiones. Puede, de todas formas, usarlos entre el operador y sus operandos. Sin embargo, si coloca un espacio antes de un operador (p.e. +), será necesario que coloque también uno después del mismo. La única excepción se produce en las expresiones de tipo de lista (con ,), donde sólo se debería poner un espacio después de la «,», pero nunca antes. Además, también es correcto omitir el espacio en este caso. Los siguientes ejemplos muestran el uso correcto de los espacios: { int a,b; int c, d, e; int f = 4; a=b=c=d+e+f; a = b = c = d + e + f; if(a == 4) { a = b = c = (d+e)/2; } while(b<3) c--; arts_debug("%d\n", c); } Los siguientes ejemplos muestras como no se deben utilizar los espacios. En las llamadas de función, después de if, while, for, swith y demás, no se debe escribir un espacio. { // MAL: si escribe una lista, los espacios sólo deben ir después de la "," int a , b , c , d , e , f; // MAL: no se han utilizado los espacios simétricamente con el operador = a= 5; // MAL: if se considera una función y no debe ir seguida por un espacio if (a == 5) { } // MAL: nunca escriba espacios después de while while (a--) b++; // MAL: los nombres de funciones no deben ir seguidos por un espacio arts_debug ("%d\n", c); // MAL: tampoco los nombres de los miembros Arts::Object o = Arts::Object::null (); } Nombres de los archivos fuente Los archivos fuente no deben tener mayúsculas en el nombre. Deben tener el nombre de la clase cuando implementen una sola clase. Su extensión es .cc si se refieren a código independiente de &Qt;/&GUI;, y .cpp si se refieren a código dependiente de &Qt;&GUI;. Los archivos de implementación para las interfaces deben llamarse foo_impl, si Foo fuese el nombre del interfaz. Los archivos &IDL; deben llamarse de una forma descriptiva de la colección de interfaces que contienen, también en minúsculas. No es bueno, concretamente, llamar al un archivo &IDL; como la propia clase, puesto que el intercambiador de mcopclass y las entradas de información de tipo colisionarán.