# Contribuire a &arts;

## Come puoi aiutare

Il progetto &arts; può utilizzare aiuti da parte di programmatori per rendere le applicazioni multimediali esistenti compatibili con &arts;, per scrivere nuove applicazioni multimediali e per aumentare le capacità di &arts;. Comunque, non devi essere per forza uno sviluppatore per contribuire. Possiamo anche utilizzare l'aiuto da parte di collaudatori per segnalare bug, da parte di traduttori per tradurre il testo dell'applicazione e la documentazione in altre lingue, da parte di artisti per il disegno di bitmap (specialmente per i moduli di artsbuilder), da parte di musicisti per creare moduli &arts; di esempio, e da parte di scrittori per la scrittura e la rilettura della documentazione.

## Mailing List

La maggior parte delle discussioni sullo sviluppo di &arts; avvengono su due mailing list. Queste sono il posto per discutere nuove caratteristiche e idee di implementazione o per chiedere aiuto sui problemi.

La mailing list &kde; Multimedia è per la discussione generale su &kde; Multimedia, compresi &arts; e le applicazioni multimediali come &noatun; e &aktion;. Puoi iscriverti dalla pagina web a http://www.kde.org/mailinglists.html, o inviare una e-mail con oggetto `subscribe tuo indirizzo e-mail` a kde-multimedia-request@kde.org. La lista viene inoltre archiviata a http://lists.kde.org.

La mailing list &arts; riguarda gli argomenti specifici di &arts;, tra cui l'uso di &arts; fuori da &kde;. Per iscriverti, invia una e-mail contenente come corpo del messaggio `subscribe tuo indirizzo e-mail` a arts-request@space.twc.de. La lista viene archiviata a http://space.twc.de/~stefan/arts-archive.

## Standard per il codice

Per una lettura consistente tra tutti i sorgenti, è importante mantenere un unico stile di scrittura del codice per tutti i sorgenti di &arts;. Per favore, anche se scrivi solo un modulo, cerca di scrivere/formattare allo stesso modo il tuo codice, dato che questo renderà più semplice la manutenzione dell'albero dei sorgenti a persone diverse, e la copia di pezzi di un sorgente in un altro.

Nomi per le funzioni membro

  Stile &Qt;/&Java;. Questo significa l'uso delle maiuscole come separazione delle parole e la prima lettera sempre minuscola; nessun underscore (_).

  Questo significa, per esempio:

      createStructureDesc()
         updateWidget();
         start();

Classi membro

  Le classi membro non hanno mai la maiuscola, come menubar o button.

  Quando ci sono funzioni di accesso, lo standard dovrebbe essere come &MCOP;, cioè, quando hai un membro lungo `foo`, che non dovrebbe essere visibile direttamente, crea:

      foo(long new_value);
         long foo();

  Funzioni che prelevano e impostano i valori. In questo caso, il valore reale di `foo` dovrebbe essere memorizzato in &lowbar;foo.

Nomi delle classi

  Tutte le classi dovrebbero avere la maiuscola ad ogni inizio di parola, il che significa `ModuleView`, `SynthModule`. Tutte le classi che appartengono alle librerie dovrebbero utilizzare il namespace &arts;, come `Arts::Soundserver`.

  Le implementazioni delle classi &MCOP; dovrebbero essere chiamate `Class&lowbar;impl`, come `SoundServer&lowbar;impl`.

Parametri

  I parametri non hanno mai la maiuscola.

Variabili locali

  Le variabili locali non hanno mai la maiuscola, e possono avere nomi come `i`, `p`, `x`, &etc; dove appropriato.

Larghezza delle tabulazioni

  Una tabulazione è lunga come 4 spazi.

Gli spazi nelle espressioni

  Normalmente non hai bisogno di usare spazi nelle espressioni. Comunque puoi usarli tra gli operatori ed i lori operando. Comunque, se metti uno spazio prima di un operatore (ad esempio, +), devi metterne uno anche dopo di esso. L'unica eccezione a questo sono le espressioni simili a liste (con la ,), nelle quali dovresti mettere solo uno spazio dopo la ",", ma non prima. Va bene anche se ometti questi spazi comunque.

  I seguenti esempi mostrano l'utilizzo corretto degli spazi:

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

  I seguenti esempi mostrano come gli spazi non vanno utilizzati. Per le chiamate di funzione, dopo if, while, for, switch, e così via, non ci vuole nessuno spazio.

      {
          // SBAGLIATO: se scrivi una lista, usa gli spazi solo dopo la ","
          int a , b , c , d , e , f;

          // SBAGLIATO: uso asimmetrico degli spazi per l'operatore =
          a= 5;

          // SBAGLIATO: if è considerato una funzione, e non viene seguito da uno spazio
          if (a == 5) {
          }

          // SBAGLIATO: non usare uno spazio dopo while
          while (a--)
              b++;

          // SBAGLIATO: i nomi delle funzioni non vengono seguiti da uno spazio
          arts_debug ("%d\n", c);

          // SBAGLIATO: nemmeno i nomi dei membri
          Arts::Object o = Arts::Object::null ();
      }

Nomi dei file sorgente

  I file sorgente non dovrebbero avere nessuna maiuscola nel nome. Dovrebbero avere il nome della classe quando implementano una singola classe. La loro estensione è `.cc` se si riferiscono a codice indipendente da &Qt;/&GUI;, e `.cpp` se si riferiscono a codice dipendente da &Qt;/&GUI;. I file di implementazione per le interfacce dovrebbero essere chiamati `foo`, se Foo è il nome dell'interfaccia.

  I file &IDL; dovrebbero essere chiamati in un modo che descriva la raccolta di interfacce che contengono, sempre tutto in minuscolo. Specialmente non è una buona idea chiamare un file &IDL; come la classe, dato che il trader .mcopclass e le voci di informazione sui tipi colliderebbero, in questo caso.