# Contribuer à &arts;

## Comment nous aider

Le projet &arts; peut profiter de l'aide de développeurs pour rendre les applications multimédia existantes compatibles avec &arts;, pour écrire de nouvelles applications multimédia, et pour améliorer les fonctionnalités de &arts;. Cependant, vous pouvez contribuer sans être développeur. Nous avons besoin de l'aide de testeurs qui nous soumettent des rapports de bogue, de traducteurs pour l'application et la documentation dans d'autres langues, d'artistes pour réaliser les graphismes (particulièrement pour les modules de artsbuilder), de musiciens pour créer de nouveaux modules pour &arts;, et de rédacteurs pour écrire ou améliorer la documentation.

## Listes de discussion

Les discussions relatives au développement de &arts; ont lieu sur deux listes de discussions. Nous y parlons des nouvelles idées de caractéristiques et d'implantations, et nous y résolvons un certain nombre de problèmes.

La liste de discussion &kde; Multimedia concerne les problèmes multimédia de &kde; en général, y compris &arts; et les applications multimédia comme &noatun; et &aktion;. Vous pouvez vous y inscrire depuis la page web à http://www.kde.org/mailinglists.html ou envoyer un message électronique dont le sujet est `subscribevotre adresse électronique` à kde-multimedia-request@kde.org. Cette liste est aussi archivée à http://lists.kde.org.

La liste de discussion de &arts; est spécifique à &arts;, y compris les utilisations de &arts; indépendamment de &kde;. Pour vous inscrire, envoyez un message électronique avec le message `subscribe votre adresse électronique` à arts-request@space.twc.de La liste est archivée à http://space.twc.de/~stefan/arts-archive.

## Style de programmation

Pour obtenir un code source homogène, il est important de garder un style de programmation dans tous les sources de &arts;. Même si vous écrivez simplement un module, essayez d'écrire et formater votre source en conséquence, de façon à faciliter le travail de différentes personnes dans la gestion des sources, et faciliter la copie de morceaux de codes d'un source vers un autre.

Nom des fonctions membres

  Style &Qt;/&Java;, ce qui signifie une majuscule au début de chaque mot, et la première lettre toujours en minuscule ; aucun caractère de soulignement.

  Ceci signifie par exemple :

      createStructureDesc()
         updateWidget();
         start();

Membres de classes

  Les membres de classes s'écrivent en minuscule, comme par exemple menubar ou button.

  Lorsqu'il y a des fonctions d'accès, le standard devrait être celui de &MCOP;, c'est-à-dire lorsque vous avez un membre `foo` de type long, qui ne doit pas être visible directement, vous créez les fonctions :

      foo(long new_value);
         long foo();

  pour récupérer et envoyer les valeurs. Dans ce cas, la valeur réelle de `foo` devrait être stockée dans &lowbar;foo.

Nom des classes

  Toutes les classes doivent s'écrire avec une majuscule au début de chaque mot, par exemple `ModuleView`, `SynthModule`. Les classes qui appartiennent aux librairies doivent utiliser les espaces de noms de &arts;, comme `Arts::Soundserver`.

  Les implantations des classes &MCOP; doivent être appelées `Class&lowbar;impl`, comme par exemple `SoundServer&lowbar;impl`.

Paramètres

  Les paramètres sont toujours en minuscule.

Variables locales

  Les variables locales sont toujours en minuscule, et ont des noms comme `i`, `p`, `x`, &etc;

Largeur de tabulation (largeur du décalage)

  Une tabulation correspond à 4 espaces.

Espaces dans les expressions

  Vous n'avez normalement pas à utiliser d'espaces dans les expressions. Vous pouvez cependant les utiliser entre les opérateurs et leurs opérandes. Si vous placez un espace avant un opérateur (&pex; +), vous devez alors en placer un après l'opérateur. La seule exception correspond aux expressions de type liste (avec une virgule), où ou ne devez placer un espace qu'après la virgule, mais pas avant. Vous pouvez également ommettre la virgule ici.

  Les exemples suivants montrent une bonne utilisation des espaces :

      {
          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);
      }

  Les exemples suivants montrent comment ne pas utiliser les espaces. Pour les appels de fonction, après if, while, for, switch &etc;, on ne met pas d'espace.

      {
          // MAUVAIS : si vous écrivez une liste, écrivez les espces uniquement après la virgule
          int a , b , c , d , e , f;

          // MAUVAIS : utilisation non symétrique des lesapces pour l'opérateur =
          a= 5;

          // MAUVAIS : si considéré comme fonction, et n'est pas suivi par un espace
          if (a == 5) {
          }

          // MAUVAIS : n'écrivez pas d'espace après un while
          while (a--)
              b++;

          // MAUVAIS : les noms de fonctions ne sont pas suivis par un espace
          arts_debug ("%d\n", c);

          // MAUVAIS : ni les noms de membres
          Arts::Object o = Arts::Object::null ();
      }

Noms des fichiers sources

  Les fichiers sources sont en minuscule. Ils doivent porter le nom de la classe lorsqu'ils implantent une classe unique. Leur extension est `.cc` s'ils contiennent du code indépendant de &Qt;/&GUI;, et `..cpp` s'ils contiennent du code dépendant de &Qt;/&GUI;. Les fichiers d'implantation pour les interfaces doivent être appelés `foo_impl`, si Foo est le nom de l'interface.

  Les fichiers &IDL; doivent être appelés de manière descriptive pour l'ensemble des interfaces qu'ils contiennent, aussi tout en minuscule. En particulier, il est déconseillé de donner à un fichier &IDL; le nom de la classe elle-même, car le sélecteur de fichiers .mcopclass (.mcopclass trader) et les informations de type entreront en conflit.