# 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.