Na de succesvolle installatie van de ge ntegreerde ontwikkelingsomgeving kunt u deze starten vanuit uw
Windows – startmenu. Het gebruikersoppervlak van de ge ntegreerde ontwikkelingsomgeving komt
overeen met de actuele standaards en kan intu tief bediend worden. U kunt details vinden in de Online –
Help, die u door op de [F1]- toets kunt oproepen.
6.2 Brontekst bewerken
In de editor van de ge ntegreerde ontwikkelingsomgeving voert u de brontekst van de aparte module in.
Door de zogenoemde Syntax Highlighting worden de verschillende syntax – elementen in verschillende
instelbare kleuren en schrijfstijlen getoond. Daardoor wordt de leesbaarheid van de programma's op het
beeldscherm en bij het uitprinten verhoogd. Bovendien kunnen eenvoudige schrijffouten makkelijk onder-
kend worden. De editor beschikt over de gebruikelijke functies voor het laden en opslaan van bestanden,
zoeken en vervangen van tekstpassages alsmede over Undo en Redo voor veranderingen in de bron-
tekst.
Verdere gereedschappen ter ondersteuning van uw werk zijn de automatische completering van ken-
merken tijdens het invoeren, context – sensitieve hulp bij C2 – codewoorden en module – overstijgend
zoeken naar de definitie van C2 – kenmerken in het actuele project. De exacte beschrijvingen daartoe
vindt u in de Online – Help van de geintegreerde ontwikkelingsomgeving (toets [F1]).
6.3
Richtlijnen voor de formattering van de brontekst
6.3.1
Voordelen van de uniforme formattering
Voor de syntactische en functionele correctheid van een programma is de formattering van een brontekst
zonder betekenis. In het belang van de overzichtelijkheid en de begrijpelijkheid moeten bronteksten
echter ook "optisch" correct zijn. Een stijlvol en gedisciplineerd vormgegeven brontekst volgens uniforme
richtlijnen is ook na langere tijd en ook voor andere programmeurs leesbaar en begrijpelijk.
Geformatteerde bronteksten bevatten in de regel vanaf het begin al minder fouten. Als er fouten in staan,
kan het zoeken en verhelpen daarvan in een nette brontekst eenvoudiger uitgevoerd worden.
De onderstaande richtlijnen voor de vormgeving zijn basisvoorstellen. Het staat u vrij, de voorstellen te
accepteren, te variëren of te verwerpen. Als u echter ondersteuning van Conrad Electronic wenst en
daartoe bronteksten ter controle naar ons toestuurt, kunnen deze alleen bewerkt worden als ze herken-
baar overeenkomen met de hieronder opgevoerde richtlijnen. Bij twijfel kunt u zich oriënteren op de
formattering van de standaardmodules en voorbeelden op de CD voor de C-Control II unit.
6.3.2
Commentaren
1. Een programma dient commentaren te bevatten, als dat leidt tot een wezenlijke verbetering van de
begrijpelijkheid.
2. Een commentaar dient vermeden te worden, als de zin van opdrachten ook door zelfbeschrijvende
kenmerken duidelijk kan worden.
3. Commentaren mogen niet triviaal zijn, b.v. x = 1; / / 1 aan x toewijzen
4. Einde regel – commentaren moeten op zijn minst voor opeenvolgingen van opdrachten, die niet door
spaties gescheiden zijn, links uitgelijnd onder elkaar staan.
5. Een verklarend commentaar bij een opeenvolging van opdrachten staat in een eigen regel voor deze
opdrachten, met dezelfde inspringing als deze opdrachten.
6. Commentaren zijn in één enkele taal opgemaakt, d.w.z. of helemaal in het Engels of helemaal in het
Nederlands. Commentaren dienen in dezelfde taal als de kenmerken geformuleerd te worden.
6.3.3 Kenmerken
1. Kenmerken dienen zelfbeschrijvend te zijn. Afkortingen zijn mogelijk, zo lang de betekenis in de
context zonder extra commentaren herkenbaar blijft. Bijvoorbeeld "get/MaxTemp" in plaats van
"getMaximumTemperature" is toegestaan. Alleen primitieve functies, tijdelijke variabelen voor het
opslaan van tussenresultaten, indicaties of lusvariabelen, mogen uit enkele letters of korte
tekencombinaties bestaan.
2. Kenmerken van modules, threads, functies en variabelen beginnen met een kleine letter.
3. Kenmerken van samengestelde datatypes beginnen met een hoofdletter.
4. Kenmerken van constanten bestaan alleen uit hoofdletters, onderstrepen en cijfers.
5. Kenmerken van functies moeten zo veel mogelijk met een werkwoord of een gebruikelijke afkorting
van een werkwoord beginnen (b.v. get, set, put, write, init, calc ...).
6. In langere kenmerken moeten losse woorden door onderstrepen of aparte hoofdletters bij het wisselen
van woorden gescheiden te worden, b.v. getMaxTemp of get_max_temp. U dient de eenmaal
gekozen schrijfwijze aan te houden.
48