Hallo, en welkom terug.
We starten een nieuwe rubriek.
En in deze sectie wil ik het hebben over enkele van de basisconcepten in C.
Ik wil hier enkele dingen beschrijven die we hadden in ons voorbeeld of onze
eerste uitdaging, ons hoofdprogramma.
Dus ik heb deze uitdaging, je herinnert het je waarschijnlijk nog.
Het heeft een aantal verschillende verklaringen in regels code.
Ik ga proberen om enkele van de concepten hier te behandelen. Ik ga heen en weer naar dit voorbeeld.
Het eerste dat ik wil bespreken, is het concept van een opmerking.
Dus we komen hier zo op terug. Ik wil nu naar enkele dia's gaan.
Dus commentaar wordt in een programma gebruikt om een programma te documenteren en de
leesbaarheid ervan te vergroten.
Ik heb je verteld waarom het belangrijk is dat je programma leesbaar is.
Omdat je de code gaat onderhouden en je moet ernaar kunnen kijken
en begrijpen wat het doet. Dus met opmerkingen kan
het behoorlijk
helpen bij dit concept van leesbaarheid.
Opmerkingen zijn er om u of iemand anders die uw code
leest eraan te herinneren wat het programma doet of wat een bepaalde regel code doet.
Dus opmerkingen zijn er in uw voordeel.
Opmerkingen worden door de compiler genegeerd.
Het maakt dus niet uit of je de syntaxis van opmerkingen volgt, de compiler zal
geen fouten maken, wat er ook in de opmerking staat.
Dus nogmaals, ze zijn erg handig en je wilt ze gebruiken in je programma's.
En ze zijn een basisconcept van alle programmeertalen.
En dus is er hier eigenlijk niets nieuws te zien.
Nogmaals, je mag als programmeur wat code schrijven, er binnen 6 maanden op
terugkomen en je herinnert je misschien
niet meer waarom je de code hebt geschreven zoals je deed.
Misschien begrijp je de functionaliteit niet, misschien begrijp je de logica niet.
Door een opmerking in de code te
plaatsen, kan het een aanzienlijke hoeveelheid tijd besparen die u verspilt aan het opnieuw leren van dingen, met
name het opnieuw leren van die code.
Of stel je voor dat je
wat code hebt geschreven en het is een groot programma, er werken veel programmeurs
aan en iemand anders moet naar die code kijken.
Als er opmerkingen zijn en ze beschrijven wat de code doet,
dan zal die andere persoon die code veel sneller kunnen begrijpen.
Het wordt beter leesbaar. Dus nogmaals, opmerkingen helpen de leesbaarheid of
ze helpen de leesbaarheid van de programmeur die de code heeft geschreven, of
ze helpen de leesbaarheid van iemand anders die naar code kijkt.
Je kunt die broncode gemakkelijk bekijken en dan snel begrijpen wat de code doet.
En dus wil je commentaar geven in je code.
De syntaxis voor het verstrekken van opmerkingen in uw code is
dat er twee manieren zijn waarop u opmerkingen in uw code kunt plaatsen.
En nogmaals, dit lijkt erg op java, erg op veel talen.
Maar in c kunt u opmerkingen met meerdere regels of enkele opmerkingen hebben.
Als u 2 tekens gebruikt, de schuine streep gevolgd door de
asterisk, betekent dit een opmerking met meerdere regels, een
opmerking die vele regels beslaat.
En de schuine streep ster markeert het begin van die opmerking.
En als je deze opmerkingen met meerdere regels hebt omdat ze een begincommentaar hebben,
moet je iets hebben dat zegt dat het eindigt.
Dus om de opmerkingen te beëindigen, plaats je de tekens een asterisk
naar voren slash aan het einde zonder spaties ertussen.
En dus wordt alles tussen de voorwaartse schuine streep
en de voorwaartse schuine streep van de eindster
als een opmerking beschouwd, alles
in het blauw dat. En zo kun je meerdere lijnen overspannen.
De andere manier waarop u een opmerking aan uw c-programma kunt toevoegen, is door opmerkingen van
één regel te gebruiken.
Enkele regel opmerkingen zijn slechts 2 schuine strepen naar voren.
Alles na de 2 schuine strepen op die regel wordt
door de compiler genegeerd en als commentaar beschouwd.
Alles daarna is geen commentaar, het is een nieuwe regel code.
Het hangt dus echt af van
de opmerking die u geeft of u al dan niet opmerkingen met meerdere regels of opmerkingen met één regel wilt gebruiken.
En ik ga je laten zien hoe je die in een oogwenk aan je code kunt toevoegen.
Wat betreft styling, of je nu opmerkingen met meerdere regels of opmerkingen met één
regel gebruikt, je gaat waarschijnlijk beide gebruiken, afhankelijk van wat je probeert te doen of
hoeveel regels je moet beschrijven of hoe groot je opmerking is.
In dit voorbeeld gebruiken we hier een commentaar met meerdere regels, en dit komt
normaal gesproken bovenaan het bestand te staan. Het beschrijft wie het bestand
heeft geschreven, de auteur van het bestand en vervolgens het auteursrecht.
Je kunt ook opmerkingen geven die opvallen als er iets
heel, heel belangrijks in je code gebeurt door
veel sterretjes te plaatsen.
En dus het tweede voorbeeld hier, waar staat dat dit een zeer belangrijke opmerking
is, valt het echt op door al die sterretjes.
Het is dus een andere stijl dan de kopcommentaar bovenaan in
het eerste voorbeeld.
Nu het laatste voorbeeld hier, dat slechts een opmerking van één regel is, het
staat aan het einde van een regel code en het vertelt je eigenlijk gewoon wat een enkele regel doet.
Dus je ziet deze verschillende stijlen van opmerkingen met meerdere regels versus enkele regels.
Hier is een veelvoorkomend voorbeeld dat u in een programma zou zien.
Dit is een programma dat C-code bevat.
Je weet waarschijnlijk niet echt wat dit in godsnaam aan het doen is.
Maar je zou naar de opmerkingen kunnen kijken en een soort van identificeren wat er aan de hand is.
Er staat dus bovenaan een opmerking die zegt dat dit programma 2 gehele getallen optelt en de resultaten weergeeft.
Het vertelt je het doel van het
programma, wat het doet.
En dan zie je enkele opmerkingen van één regel.
En hoe weet je dat het opmerkingen van één regel zijn? Omdat ze 2 schuine strepen naar voren hebben.
U ziet dus een opmerking van één regel die zegt dat variabelen moeten worden gedeclareerd.
Je ziet een andere die zegt waarden toewijzen en hun som berekenen.
En dan zie je er een die zegt dat het resultaat moet worden weergegeven.
Elke enkele regelcommentaar beschrijft elke afzonderlijke codegroep en vertelt u wat ze aan het
doen zijn.
En dus kunt u snel naar deze
code kijken en begrijpen wat de code doet door naar de opmerkingen te kijken.
Het maakt het programma beter leesbaar.
Leesbaarheid is een voordeel omdat het de code makkelijker te onderhouden maakt.
Het is dus belangrijk om opmerkingen te gebruiken. En dit is een snel voorbeeld van het
toevoegen van opmerkingen aan een code.
Nu, hoe vaak moeten we opmerkingen gebruiken.
Er is het concept van het hebben van te veel opmerkingen.
U wilt niet dat uw code een opmerking heeft voor elke regel.
Dat vermindert eigenlijk de leesbaarheid van de code omdat deze gewoon overloopt.
Het maakt het eigenlijk moeilijker om te lezen omdat het gewoon overweldigend is.
U wilt dus niet voor elke regel code een opmerking plaatsen.
U moet uw opmerkingen verstandig kiezen en intelligent gebruiken.
Dit komt met oefening, wanneer opmerkingen moeten worden toegevoegd,
wanneer geen opmerkingen moeten worden toegevoegd, waar opmerkingen moeten worden geplaatst.
Meestal heb ik opmerkingen bovenaan mijn bronbestand met standaardinformatie
zoals de auteur, het doel, de beschrijving, de datum waarop opmerkingen
zijn gemaakt en vervolgens door mijn code worden verspreid, waarbij enkele regels
code worden beschreven waar de logica is een beetje ingewikkelder.
Ik zal niet altijd opmerkingen toevoegen voor het declareren van variabelen, omdat het nogal voor de hand ligt.
Ik mag geen opmerkingen opnemen voor bepaalde functies, beschrijvingen
omdat de beschrijving zelf misschien zinvoller is.
Het hangt allemaal af en het komt met de praktijk.
Maar wanneer u opmerkingen toevoegt, is het traditioneel een goed idee om die opmerkingen
toe te voegen wanneer u de code schrijft.
Ten eerste omdat als je het dan doet, het programma becommentarieerd wordt
en je het niet vergeet.
Het is ook gemakkelijker om het programma te documenteren waarom
u werkelijk begrijpt wat het doet terwijl u de code schrijft.
Nog vers in je geheugen, je hoeft niet een maand later terug te
komen en te zeggen wat ik hier bedoelde en nu moet ik een opmerking toevoegen.
Dus voeg de opmerkingen toe terwijl je de code schrijft.
En de opmerkingen kunnen ook helpen wanneer u uw fouten probeert te vinden en
op te lossen, tijdens de foutopsporingsfase. Als er logische fouten zijn, kun
je naar de opmerkingen kijken en kun je een soort isoleren, nou, dit
is de fout die is opgetreden.
Deze opmerking komt overeen met die functionaliteit.
Ik wed dat de fout in deze groep code zit. Het helpt je dus om fouten bij het debuggen te isoleren.
Een opmerking kan u helpen het programma te lezen, maar het kan ook de weg wijzen naar
de bron van een logische fout, dus opmerkingen zijn belangrijk.
Het andere argument bij het geven van commentaar is
dat er weer een groot debat is met programmeurs, hoeveel commentaar geeft u?
En er is een mooi boek met de naam Clean Code, waarin wordt gesproken
over het schrijven van kwaliteitscode. Geloof het of niet,
er kan goede of slechte code zijn, en dat wordt
de kwaliteit van de code genoemd.
U wilt hoogwaardige code schrijven.
We zullen hier tijdens de cursus over praten, maar veel studenten die nieuwe talen leren, denken dat zolang de output
overeenkomt met wat ik nodig heb, het niet uitmaakt
hoe ik de code schrijf. Dat is niet waar.
Want nogmaals, onthoud die onderhoudsfase.
Onthoud dat het product of
het programma dat u uitbrengt, misschien een aantal jaren in het veld zal zijn.
Dus als je bestaande bugs wilt vinden of nieuwe functies wilt toevoegen, is het
belangrijk dat de code van zeer hoge kwaliteit is, gemakkelijker te onderhouden, heel
losjes gekoppeld en zeer samenhangend.
En we zullen over deze concepten praten terwijl we ze doornemen.
We gaan de hele klas code van hoge kwaliteit schrijven.
Een van de manieren om code van hoge kwaliteit te schrijven, is door opmerkingen te
geven, maar ook door zelfgedocumenteerde opmerkingen.
Wat dit betekent, is echt betekenisvolle namen gebruiken. Dit is waar dat Clean Code-boek over gaat.
Gebruik een betekenisvolle naam wanneer u een variabele maakt.
Dus als je naar de variabele kijkt, weet je precies waarvoor deze wordt gebruikt, dan
hoef je geen commentaar te geven.
Als je een functie hebt die 2 getallen optelt, noem de functie dan 2 getallen optellen.
Heb je dan een opmerking nodig om te zeggen wat die functie doet, nee.
Omdat de naam je vertelt wat het doet.
Betekenisvolle namen zijn dus een goede manier om zelfdocumenterende opmerkingen te maken.
Laten we teruggaan naar ons voorbeeld van onze uitdaging
en ik wil je precies laten zien hoe
je opmerkingen kunt toevoegen en waar je ze kunt toevoegen.
En je zult merken dat de compiler deze opmerkingen gaat negeren.
Dus in ons eerste voorbeeld hier, dat een basisprogramma is,
voeg ik meestal opmerkingen met meerdere regels toe aan de bovenkant van het bestand vóór regels code.
En onthoud dat we die opmerkingen met meerdere regels kunnen toevoegen door een schuine streep, ster of asterisk
op te geven om de opmerking te starten.
En dan is alles tussen de
opmerking de opmerking,
alles tussen de ster en de asterisk.
En je zult merken dat als ik die schuine streep ster doe, alles grijs
is, want dat zegt me dat ik mijn eindcommentaar nu niet heb.
Dus je moet die schuine streep naar voren
toevoegen om de opmerking te beëindigen. En je zult zien dat de kleuren nu veranderen.
Dit is waarom ik graag een IDE gebruik omdat het je veel vertelt met deze
kleurgecoördineerde opmaak.
Dus alles tussen de schuine streep is het begin van een
opmerking met meerdere regels, alles vóór de ster naar voren is de beschrijving
of het einde van de opmerking met meerdere regels.
En meestal zet ik bovenaan het bestand iets als
auteur en dan zet ik mijn naam en dan zet ik misschien een doel.
Dit is meestal een goede gewoonte en ik zal zoiets als dit
programma plaatsen, mijn naam op het scherm afdrukken.
En dan zal ik meestal een datum geven waarop het is gemaakt, wat de datum ook is.
En dat is een voorbeeld van commentaar met meerdere regels bovenaan. En dan zal ik commentaar geven
in de hele code. Gewoonlijk opmerkingen met één regel of
opmerkingen met meerdere regels, het hangt er gewoon van af hoeveel opmerkingen er zijn.
Dus misschien zijn we niet bekend met deze code. En ik zou kunnen zeggen dat je weet dat
2 schuine strepen naar voren een opmerking van één regel is. Ik kan zeggen dat deze
code mijn naam weergeeft.
En nogmaals, als ik deze schuine strepen of deze meerregelige
opmerkingen geef, negeert de compiler ze. Kortom, je kunt er alles in doen wat je wilt en het maakt niet uit.
Er is geen syntaxis die u moet volgen, er is niets.
Het negeren van alles wat hier grijs gekleurd is, wordt gezien
als een opmerking.
Commentaar is dus een fundamenteel element van elk programma.
Ik wilde ze al vroeg beschrijven omdat ik ze zal gebruiken, en je
zou ze moeten toevoegen terwijl je je code schrijft.
Ook met opmerkingen binnen de IDE zijn
er momenten waarop u uw code aan het compileren bent en het allemaal mislukt.
En dus zijn er momenten waarop u alles wilt becommentariëren of codeblokken
wilt becommentariëren om te proberen uw probleem te debuggen, probeer uw fout te isoleren.
U kunt meerdere regels code markeren en vervolgens gaat
u naar de bewerking in het menu en kunt u commentaar
geven of commentaar opheffen.
Als je commentaar zegt, zal het commentaar geven op al die code
die je hebt gemarkeerd.
En dan kun je opnieuw compileren en misschien heb je geen compilerfout meer.
Het is een manier om fouten tijdens runtime of tijdens het compileren te isoleren.
Dus de IDE heeft een aantal
leuke tools waarmee je automatisch meerdere regels kunt becommentariëren door te markeren
en te wisselen.