Hjælp til med &arts;
Hvordan du kan hjælpe til
&arts;-projektet behøver hjælp fra udviklere for at at tilføje understøttelse for &arts; i eksisterende multimedieprogrammer, skrive nye multimedieprogrammer og forbedre &arts;' muligheder. Du behøver dog ikke være en udvikler for at bidrage. Vi behøver også hjælp fra testere til at indsende fejlrapporter, oversættere til at oversætte programteksten og dokumentationen til andre sprog, grafikere til at oprette ikoner (især for artsbuilder moduler), musikere til at lave &arts;-moduleksempler, og forfattere til at skrive eller gennemse dokumentation.
E-mail-lister
De fleste udviklingsdiskussioner om &arts; finder sted via to e-mail-lister. Dette er stedet at diskutere nye funktioner og implementeringsidéer og at spørge efter hjælp med problemer.
&kde;'s multimedie e-mail-liste er til for generelle &kde; multimediespørgsmål inklusive &arts; samt multimedieprogrammer såsom &noatun; og &aktion;. Du kan abonnere fra netsiden på http://www.kde.org/mailinglists.html eller sende e-mail med emnet subscribe din-e-mail-adresse til kde-multimedia-request@kde.org. Listen findes også arkiveret på http://lists.kde.org.
E-mail-listen for &arts; er til for spørgsmål som kun berører &arts;, inklusive brug af &arts; udenfor &kde;. For at abonnere, send e-mail til arts-request@space.twc.de med meddelelsesteksten subscribe din-epostadresse. Listen arkiveres på http://space.twc.de/~stefan/arts-archive.
Kodningsstandarder
For at opnå en konsekvent læsning af al kildekode, er det vigtigt at holde kodningsstilen ens i hele &arts;' kildekode. Vær derfor rar og forsøg at skrive/formatere din kildekode i overensstemmelse med dette, også selvom du kun skriver et modul, eftersom det gør det enklere for forskellige personer at vedligeholde kildekodetræet, og lettere at kopiere dele af kildekoden fra en fil til en anden.
Navngivning af medlemsfunktioner
&Qt;/&Java;-stil. Dette betyder at store bogstaver bruges til at markere nye ord, og at det første bogstav altid er lille. Ingen understregninger.
Dette betyder for eksempel:
createStructureDesc()
updateWidget();
start();
Klassemedlemmer
Klassemedlemmer har ikke store bogstaver, som for eksempel menubar eller button.
Når der er funktioner som bruges til adgang, skal standarden som bruges være ifølge &MCOP;-måden, dvs. hvis der er et "long" medlem foo, som ikke skal være synlig, så laves:
foo(long new_value);
long foo();
funktioner for at hente eller sætte en værdi. I dette tilfælde, skal den rigtige værdi for foo opbevares i _foo.
Klassenavne
Alle klasser skal have store bogstaver for hvert ord, hvilket betyder ModuleView, SynthModule. Alle klasser som hører til biblioteker skal bruge &arts;-navnerummet, såsom Arts::Soundserver.
Implementeringer af &MCOP;-klasser skal døbes Class_impl, som for eksempel SoundServer_impl.
Parametre
Parametre har altid små bogstaver.
Lokale variabler
Lokale variabler har altid små bogstaver, og kan have navne såsom i, p, x osv. hvis det passer.
Tabulatorbredde (skiftbredde)
Et tabulatortegn er lige så meget som fire blanke tegn.
Mellemrum i udtryk
Normalt behøver du ikke bruge mellemrum i udtryk. Du kan i alle tilfælde bruge dem mellem operatorer og deres operander. Hvis du skriver et mellemrum før en operator (f.eks. +), skal du også skrive et mellemrum efter operatoren. Den eneste undtagelse fra dette er udtryk som ligner lister (med ,), hvor du kun skal bruge et mellemrum efter ",", men ikke før. Det er også i orden at udelade mellemrum her.
Følgende eksempel demonstrerer god brug af mellemrum:
{
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);
}
Følgende eksempel demonstrerer hvordan man ikke skal bruge mellemrum. For funktionskald, efter if, while, for, switch og så videre, skrives intet mellemrum.
{
// DÅRLIGT: Hvis du skriver en liste, skriv kun mellemrum efter ","
int a , b , c , d , e , f;
// DÅRLIGT: ikke symmetrisk brug af mellemrum for = operatoren
a= 5;
// DÅRLIGT: Hvis det anses at være en funktion, og ikke følges af et mellemrum
if (a == 5) {
}
// DÅRLIGT: skriv ikke et mellemrum efter while
while (a--)
b++;
// DÅRLIGT: Funktionsnavne følges ikke af et mellemrum
arts_debug ("%d\n", c);
// DÅRLIGT: heller ikke medlemsnavne
Arts::Object o = Arts::Object::null ();
}
Navngivning af kildekodefiler
Kildekodefiler skal ikke have store bogstaver i navnet. De skal have samme navne som klassen hvis de implementerer en enkelt klasse. Deres filendelse skal være .cc hvis de indeholder &Qt;- og grafikuafhængig kode, og .cpp hvis de indeholder &Qt;- og grafikafhængig kode. Implementeringsfiler for grænseflader skal benævnes foo_impl, hvis Foo er grænsefladens navn.
&IDL;-filer skal benævnes på en beskrivende måde med tanke på den samling grænseflader de indeholder, også helt med små bogstaver. I særdeleshed er det ikke godt at benævne en &IDL;-fil som klassen selv, eftersom .mcopclass-handleren og typeinfoposterne så vil kollidere.