Inspringen
Wat veel mensen vergeten bij programmeren is dat de layout net zo belangrijk is als de inhoud van de code. Het is leuk dat een programma iets moois doet, als niemand incluis jezelf er later nog iets van snapt is het waardeloos. Belangrijkste manier om overzichtelijke code te schrijven is goede indentering. Lees bijvoorbeeld:
Fout
C++:
1
2
3
4
5
6
7
8
9
10
| if(ConditionA == true &&
ConditionB == false) {
switch(ConditionC) {
case A: printf("Tis A!");
break;
case B:
printf("Tis B!"); break; }
} else {
printf("Tis foutgelopen!");
} |
Tegenover:
Goed
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| if(ConditionA == true &&
ConditionB == false)
{
switch(ConditionC)
{
case A:
printf("Tis A!");
break;
case B:
printf("Tis B!");
break;
}
}
else
{
printf("Tis foutgelopen!");
} |
De control flow van de tweede variant is een stuk sneller te analyseren, wat je helpt bij debuggen en wat ons helpt bij het begrijpen van jouw code. Er zijn meerdere manieren van indenteren:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| // Inspringen achter nest
if(Condition)
{
// Do something
}
// Inspringen op blok
if(Condition)
{
// Do something
}
// Inspringen achter code
if(Condition) {
// Do something
} |
Dit zijn de 3 meest gebruikte indenteringsvormen, en ondanks dat de 3e de compactste is kun je die het beste niet gebruiken: vooral achter lange if- en while-statements zie je de accolade nogal eens over het hoofd. De eerste 2 zijn een kwestie van smaak, net zoals of je inspringt met 2 of 4 spaties. Andere aantallen spaties worden zelden gebruikt.
Wat je ook kiest:
wees consequent!!! Niets is zo irritant lezen als opeenvolgende stukken code met andere indenteringsmethodes...
Ook bij het schrijven van functies met veel parameters en/of baseclasses moet je je indenteringen in de gaten houden, bijvoorbeeld een constructor als deze:
C++:
1
2
3
4
5
6
7
8
| MyClass::MyClass(const MyClass &p_Parent,
int p_ClassIndex,
const String &p_Name)
:MyBaseClass(p_Parent, p_ClassIndex),
m_Name(p_Name)
{
// Constructor code
} |
Dit soort dingen moet je een beetje een eigen stijl in ontdekken, zolang het maar overzichtelijk en
consequent is gaat het meestal wel goed.
Naamgeving
De naamgeving binnen code is een heel belangrijk element van de onderhoudbaarheid van je code. De beste code kan nog erger dan bij slechte indentering vernaggelt worden door onduidelijke variabelen. Stel je het volgende stukje code voor:
C++:
1
2
3
4
5
6
7
| void doshitinthebushwithparams(int* p, char* a3, const char zz[])
{
int a1, a6, z3, g4[mycusval];
char* foep, noep, a2, zoep;
// Etc.
} |
De parameternamen zijn onleesbaar, de lokale variabelen zijn onleesbaar, je hebt geen idee wat waarvoor bestaat, van welk type het is, en tot overmaat van ramp sta je een half uur op de functienaam te staren voor je doorhebt wat er staat. Dat moet beter kunnen
Eerste gouden regel: computers hebben tegenwoordig honderden megabytes geheugen, geen kilobytes meer zoals vroeger. De compilers gaan dus echt niet crashen als je langere namen gebruikt dan 3 bytes, dus
gebruik die faciliteiten en maak duidelijke namen voor alles!!!
Functienamen worden door vrijwel iedereen hetzelfde geschreven, namelijk CamelCased. Dit houdt in dat je alle woorden zonder interpunctie aan mekaar plakt en ieder woord begint met een hoofdletter. In het voorbeeld hierboven dus:
C++:
1
| void DoShitInTheBushWithParams(...) |
Wat al een stuk duidelijker is dan de eerste versie
Java en C# programmeurs zijn over het algemeen gewend om methodes en variabelen met een kleine letter te beginnen om het onderscheid te maken met classes e.d., bijv.:
Java:
1
2
3
4
5
6
7
8
9
10
| class MyClass {
private int isNoValue;
public MyClass () {
this.isNoValue = null;
}
public void doNothing () {
}
} |
Vooral door C en C++ programmeurs worden een hoop verschillende prefixen (voorvoegsels) gehanteerd om de code leesbaar te houden. De beroemdste is de zogenaamde Hungarian notation, en daar de hele Win32 API van Microsoft deze gebruikt kun je hem maar beter kennen
Zie een praktijkvoorbeeld:
C:
1
2
3
4
5
6
7
8
| int DrawTextEx(
HDC hdc, // handle to DC
LPTSTR lpchText, // text to draw
int cchText, // length of text to draw
LPRECT lprc, // rectangle coordinates
UINT dwDTFormat, // formatting options
LPDRAWTEXTPARAMS lpDTParams // more formatting options
); |
We negeren even de datatypes en kijken puur naar de variabelenamen. Hungarian is erop gebaseerd dat je het type in kleine letters als prefix hanteert voor de naam, waardoor je in code nooit meer onduidelijkheid hebt over wat een variabele nu ook alweer was. Zie in dit voorbeeld uitgeschreven:
code:
1
2
3
4
5
6
| hdc = Handle to Device Context
lpchText = Long Pointer to CHaracters
cchText = Count of CHaracters
lprc = Long Pointer to ReCtangle
dwDTFormat = DWord
lpDTParams = Long Pointer |
Zoals je ziet gebruikt Microsoft hier en daar zelfs de typeaanduiding als afdoende beschrijving (lprc en hdc). Dit is an sich sloppy Hungarian notation maar als je Microsoft heet kun je alles maken. Zolang het maar duidelijk is en dat is het in ieder geval
Een beknopt overzicht van Hungarian prefixes:
code:
1
2
3
4
5
6
| BOOL fFlag; // f = Flag oftewel een boolean
char bVariable; // b = Byte oftewel een char
DWORD dwValue; // dw = Double Word oftewel een long
HWND hMainWindow; // h = Handle (Windows datatype)
int iNumber; // i = Integer
void* pvData; // p = pointer (in dit geval een Pointer to Void) |
Hungarian is een mooi concept, maar de oplettende lezer zal er al een wazigheidje in ontdekt hebben: het schrijft voor dat je volledig beschrijvende namen gebruikt. En zoals je zag valt Microsoft vervolgens al voor de verleiding om de hele naam maar weg te laten als de type-prefix al duidelijk genoeg is. En dat is het andersom nog vaker: als je je af gaat vragen of de variabele Naam van het type integer of string is ben je fout bezig
Sommige programmeurs kiezen er daarom voor om het hele concept Hungarian overboord te gooien in ruil voor een ander mechanisme dat andere onduidelijkheden vermijd: die met scopes. Want dat mijn variabele Index een int is geloof ik wel, maar was het nu een global, een member, een parameter of een lokale variabele?
Zie het volgende extreem gezochte stukje code om het nut te illustreren van deze methode:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| const int c_Index = 684;
int g_Index = 0;
class MyClass
{
private:
int m_Index;
public:
int SwapIndexesTotallyAround(int p_Index)
{
int l_Index;
l_Index = m_Index;
m_Index = g_Index;
if(p_Index > 684)
g_Index = p_Index;
else
g_Index = c_Index;
}
} |
Ondanks dat het extreem gezocht is is dit begrijpelijk, en wel doordat we van iedere variabele een aanduiding geven waar ie vandaan komt en waar ie staat. Het volgende lijstje illustreert alle prefixes:
code:
1
2
3
4
5
6
7
| l_Local
m_Member
p_Parameter
c_Constant
g_Global
t_Type
e_Enumerate |
De laatste 2 behoeven wat verdere uitleg, en wel met dit stukje code:
C++:
1
2
3
4
5
6
7
8
9
| typedef unsigned char t_Byte; // Een typeaanduiding
typedef enum
{
e_OtUnary,
e_OtBinary,
e_OtTernary
} t_OperatorType;
} |
Bij enums kies ik er in dit geval zelfs voor om de hoofdletters van de typenaam in de enumerate te gebruiken om verwarren tussen meerdere verschillende enums (denk aan opslagformaat Binary bijvoorbeeld!) te voorkomen.
De laatste gouden tip
Voorkom debug hell tussen scopes en plaats al je lokale variabelen aan het *BEGIN* van de functie en zet er *EEN* per regel. Ja dit kost een hoop ruimte, maar houdt je code zoveel meer manageable. Dit houdt dus ook in dat je geen
for(int i = ...) mag doen maar die i (of liever l_Index) aan het begin van de functie definieert. Hiermee voorkom je de volgende perfect compilerende crime:
C++:
1
2
3
4
| for(int i = 0; i != 30; i++)
for(int i = 0; i != 20; i++)
for(int i = 0; i != 10; i++)
// Do something until the end of days |
). Iedereen is welkom om commentaar te leveren en vragen te stellen!
karakters inneemt. Dit kan bij een andere tabinstelling de indentatie (qua uiterlijk) totaal ver****ken. Zelf gebruik ik dus totaal geen tabs in source code.
:strip_exif()/u/7759/red_cat.gif?f=community)
/u/56680/gurgi.png?f=community)
:strip_exif()/u/80759/monstermania_small.gif?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
:strip_exif()/u/11775/SoulTaker.gif?f=community)
/u/1830/acm.png?f=community)
:strip_icc():strip_exif()/u/71967/Grimlock.jpg?f=community)
:strip_icc():strip_exif()/u/749/crop5f57e8bdbe9f4_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/13212/avatar-keyboard.jpg?f=community){kind=avatar}