# Programmeren in C/Stijl en structuur

Alle hogere programmeertalen zijn bedoeld voor de mens. Het is vrijwel onmogelijk om een substantieel programma in machinetaal te schrijven, aangezien dat uitsluitend uit numerieke codes bestaat. Leesbaarheid van de code is dan essentieel omdat, als het eenmaal geschreven is, een programma moet worden onderhouden en onderhoud nu eenmaal onmogelijk is als de broncode niet te begrijpen is.
Professionele programmeurs en bedrijven houden er dan ook vaak coding standards op na (bijvoorbeeld de Indian Hill coding standards), die precies beschrijven hoe de stijl en structuur van de broncode eruit dient te zien, welke regels er gelden voor naamgeving en waar commentaar vereist is. Het is vaak de stijl die in één oogopslag duidelijk maakt of een stuk code door een professional, een beunhaas of een amateur is geschreven. In dit boek houden we ons aan de hieronder beschreven eenvoudige regels om de broncode leesbaar te houden.

## Statements en blokken

De programmeertaal C leunt sterk op het samenspel van statements en blokken. Een statement is een enkele programmeeropdracht en eindigt altijd met een punt-komma (;). Het volgende is bijvoorbeeld een enkel statement:
Daarnaast is er in C een manier om een of meer statements te groeperen in een blok. Dit is vaak nodig na bepaalde taalconstructies, zoals loops en functies om de statements bij elkaar te houden. Een blok begint altijd met een open-accolade ( en eindigt met een sluit-accolade). Dit is een voorbeeld van een blok met een paar statements in een functie:
Een blok zonder statements, dus { }, mag ook als een enkele punt-komma geschreven worden. Andersom geldt niet.

## Overzichtelijkheid
### Inspringen

Voor de leesbaarheid is het noodzakelijk om de inhoud van elk blok code in te springen. Inspringen mag zowel met tabs (die afhankelijk van je editor vaak 4 of 8 spaties breed zijn) of spaties. Verder is het een goede gewoonte accolades altijd op een aparte regel te zetten, zodat in een oogopslag duidelijk is welke } bij een gegeven { hoort.
De volgende code is correct ingesprongen, met inspringingen van 4 spaties (of één tab) breed:

### Uitlijnen

Binnen regels code is het soms handig om delen uit te lijnen, zodat de code overzichtelijker wordt. Uitlijnen gaat altijd met spaties, nooit met tabs. Een voorbeeld van uitgelijnde code is de volgende set gerelateerde statements, waarbij de namen allemaal onder elkaar komen te staan:

### Lege regels

Ten slotte is het voor de overzichtelijkheid erg goed om delen van de code met een lege regel van elkaar te scheiden.

### Lijnbreedte

Gebruik regels van maximaal zo'n 80 karakters lang. Dit houdt de code compact en zorgt ervoor dat mensen met een minder breed scherm toch alles kunnen zien. In veel editors kan een lijn worden weergegeven op de gewenste kolom.

## Commentaar

Commentaar is tekst die genegeerd wordt door de compiler, maar de code verduidelijkt. Dit is handig voor andere programmeurs die uw code lezen, maar ook voor uzelf als u later nog eens terug kijkt in een stuk code. Een paar zinnen commentaar kan veel duidelijk maken over de bedoeling van broncode.

### Enkele regel commentaar

Vaak beslaat het commentaar slechts een enkele regel. Dit soort commentaar start bij // en eindigt aan het eind van de regel. In het volgende voorbeeld zijn de commentaarregels voor de overzichtelijkheid uitgelijnd (maar dit is niet noodzakelijk).

### Meerdere regels commentaar

Commentaar tussen /* en */ kan meerdere regels beslaan. Dit is vooral handig bij meerdere zinnen commentaar, of bijvoorbeeld een opsomming. In het volgende voorbeeld wordt dit soort commentaar ook toegepast aan het begin van het broncode bestand. Programmeurs doen dit vaak om het doel van een specifiek bestand te beschrijven, licentievoorwaarden neer te zetten en de wijzigingen bij te houden. Behalve in /* en */ zijn de sterretjes (*) aan het begin van elke commentaarregel niet noodzakelijk en alleen gebruikt vanwege de uitlijning:
* Vaak is het handig om niet zoveel commentaar te gebruiken als gedaan is bij de voorbeelden in dit boek. Meer ervaren programmeurs begrijpen wat de afzonderlijke regels doen en hebben vooral baat bij een beschrijving van de grote lijnen van het programma.

## Oefeningen

Beschouw de volgende varianten van een simpel programma. De lijnnummers zijn slechts ter verduidelijking en geen onderdeel van de code.
Variant A
Variant B
Variant C
Beantwoord nu de volgende vragen:
De commentaarregel had ook als enkele regel commentaar kunnen worden geschreven:

## Meer informatie

* Indian Hill Recommended C Style and Coding Standards