1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
<!-- <?xml version="1.0" ?>
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
To validate or process this file as a standalone document, uncomment
this prolog. Be sure to comment it out again when you are done -->
<chapter id="contributing">
<title>Contribuire a &arts;</title>
<sect1 id="how-to-help">
<title>Come puoi aiutare</title>
<para>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 <application>artsbuilder</application>), da parte di musicisti per creare moduli &arts; di esempio, e da parte di scrittori per la scrittura e la rilettura della documentazione. </para>
</sect1>
<sect1 id="mailing-lists">
<title>Mailing List</title>
<para>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. </para>
<para>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 <ulink url="http://www.kde.org/mailinglists.html">http://www.kde.org/mailinglists.html</ulink>, o inviare una e-mail con oggetto <userinput>subscribe <replaceable>tuo indirizzo e-mail</replaceable></userinput> a <email>[email protected]</email>. La lista viene inoltre archiviata a <ulink url="http://lists.kde.org">http://lists.kde.org</ulink>. </para>
<para>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 <userinput>subscribe <replaceable>tuo indirizzo e-mail</replaceable></userinput> a <email>[email protected]</email>. La lista viene archiviata a <ulink url="http://space.twc.de/~stefan/arts-archive">http://space.twc.de/~stefan/arts-archive</ulink>. </para>
</sect1>
<sect1 id="coding-standards">
<title>Standard per il codice</title>
<para>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. </para>
<variablelist>
<varlistentry>
<term>Nomi per le funzioni membro</term>
<listitem>
<para>Stile &Qt;/&Java;. Questo significa l'uso delle maiuscole come separazione delle parole e la prima lettera sempre minuscola; nessun underscore (_). </para>
<para>Questo significa, per esempio:</para>
<programlisting>createStructureDesc()
updateWidget();
start(); </programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>Classi membro</term>
<listitem>
<para>Le classi membro non hanno mai la maiuscola, come menubar o button. </para>
<para>Quando ci sono funzioni di accesso, lo standard dovrebbe essere come &MCOP;, cioè, quando hai un membro lungo <function>foo</function>, che non dovrebbe essere visibile direttamente, crea: </para>
<programlisting>foo(long new_value);
long foo(); </programlisting>
<para>Funzioni che prelevano e impostano i valori. In questo caso, il valore reale di <function>foo</function> dovrebbe essere memorizzato in <returnvalue>_foo</returnvalue>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Nomi delle classi</term>
<listitem>
<para>Tutte le classi dovrebbero avere la maiuscola ad ogni inizio di parola, il che significa <classname>ModuleView</classname>, <classname>SynthModule</classname>. Tutte le classi che appartengono alle librerie dovrebbero utilizzare il namespace &arts;, come <classname>Arts::Soundserver</classname>. </para>
<para>Le implementazioni delle classi &MCOP; dovrebbero essere chiamate <classname>Class_impl</classname>, come <classname>SoundServer_impl</classname>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Parametri</term>
<listitem>
<para>I parametri non hanno mai la maiuscola. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Variabili locali</term>
<listitem>
<para>Le variabili locali non hanno mai la maiuscola, e possono avere nomi come <varname>i</varname>, <varname>p</varname>, <varname>x</varname>, &etc; dove appropriato. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Larghezza delle tabulazioni</term>
<listitem>
<para>Una tabulazione è lunga come 4 spazi. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Gli spazi nelle espressioni</term>
<listitem>
<para>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. </para>
<para>I seguenti esempi mostrano l'utilizzo corretto degli spazi: </para>
<programlisting>{
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);
}
</programlisting>
<para>I seguenti esempi mostrano come gli spazi <emphasis>non</emphasis> vanno utilizzati. Per le chiamate di funzione, dopo if, while, for, switch, e così via, non ci vuole nessuno spazio. </para>
<programlisting>{
// 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 ();
}
</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>Nomi dei file sorgente</term>
<listitem>
<para>I file sorgente non dovrebbero avere nessuna maiuscola nel nome. Dovrebbero avere il nome della classe quando implementano una singola classe. La loro estensione è <literal role="extension">.cc</literal> se si riferiscono a codice indipendente da &Qt;/&GUI;, e <literal role="extension">.cpp</literal> se si riferiscono a codice dipendente da &Qt;/&GUI;. I file di implementazione per le interfacce dovrebbero essere chiamati <filename><replaceable>foo</replaceable></filename>, se Foo è il nome dell'interfaccia. </para>
<para>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. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
</chapter>
|
