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 _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_impl, come SoundServer_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.