Laten we het hebben over een andere ontwikkelaar, fundamenteel, en deze geeft commentaar op uw code.
Tot nu toe heb je me misschien zien reageren op opmerkingen bij onze scripts.
Hier heb ik bijvoorbeeld een opmerking van booleans toegevoegd, en dit vertelt de Python-interpreter, hey, dit is een opmerking, voer
dit niet uit, het is alleen voor mij.
Je kunt het gewoon negeren en doorgaan naar regel twee.
En dat zag je.
Ik deed dat gewoon in Python met het teken.
Zodra Python een hekje ziet, voegt het een opmerking toe.
En dat kun je ook na een regel doen.
Ik kan zeggen dat dit wordt toegewezen aan een variabele.
En hoewel dit eruit kan zien als twee regels, is het eigenlijk alleen de woordterugloop die plaatsvindt en je
kunt zien dat de tolk deze opmerkingen gewoon volledig negeert.
Nu, commentaar geven klinkt heel, heel eenvoudig, maar het is een belangrijk concept.
En als je een goede programmeur in alle talen wilt zijn, hebben we commentaar.
Maar er zijn goede dagen en slechte manieren om commentaar te geven.
En dit is iets dat je moet oefenen, maar hier zijn enkele belangrijke richtlijnen.
Wanneer u uw code becommentarieert, is het idee dat u waardevolle opmerkingen toevoegt,
dat wil zeggen, als ik hier een opmerking plaats die zegt: hey, dit is een tekennaamvariabele, een waarde van Andre-sterkte, een opmerking als deze
.
Is niet echt goed.
Waarom is dat?
Nou, omdat je code voor zichzelf moet spreken, toch?
Het idee is dat we code schrijven die gemakkelijk te lezen en te begrijpen is.
Het probeert niet slim te zijn.
In plaats daarvan zou het als Engels moeten lezen.
En elke Python-programmeur zou dat hier weten.
We voegen gewoon Andre toe als een waarde van naam.
We wijzen een variabele toe en voegen een opmerking als deze toe die voor zichzelf spreekt, maar voegt alleen maar rommel toe aan
uw code.
Dus er is een afweging hier, het is goed om je jas te becommentariëren voor, laten we zeggen,
als je aan teams werkt en andere ontwikkelaars komen en ze willen je code begrijpen, maar je moet onthouden dat
dit principe van code gemakkelijk te lezen is .
De enige keer dat u opmerkingen aan uw code wilt toevoegen, is, nou, als er iets heel, heel belangrijks
gebeurt, waar het misschien een beetje ingewikkeld is, besluit u eerst, hé, is deze code op een
zinvolle manier geschreven?
Als dit bijvoorbeeld variabele A was.
En dit was variabele B.
Nou, dit is misschien heel moeilijk voor iemand om te begrijpen, dus je zou kunnen zeggen dat dit een coole vlag
is.
Maar voordat je die opmerking toevoegt, wil je tegen jezelf zeggen, misschien is mijn code moeilijk te lezen, misschien
moet ik de variabele gewoon veranderen in is cool om het begrijpelijker te maken.
Nu, dit is iets dat je steeds meer verbetert en je wilt opmerkingen gebruiken als een extra hulpmiddel om je code begrijpelijk
te maken, misschien schrijf je code die over zes maanden wil je teruggaan om te
begrijpen wat je deed.
Maar onthoud dat meer opmerkingen niet noodzakelijkerwijs betere code betekenen.
U wilt beknopt zijn en de zaken eenvoudig houden, terwijl u alleen opmerkingen toevoegt wanneer dat nodig is om anderen te helpen uw
code te begrijpen, en niet probeert uw onleesbare code leesbaarder te maken.
We zullen dit onderwerp onderzoeken en u hierover gedurende de cursus advies geven.
Maar onthoud deze belangrijke basis voor ontwikkelaars, want u zult deze gedurende uw hele carrière nodig hebben.
Trouwens, dit artikel hier heeft een aantal echt belangrijke punten waarvan ik denk dat je er echt baat bij zult hebben, vooral in de
best practices voor opmerkingen, je kunt enkele van de do's en don'ts lezen en wat sommige van de beste
programmeurs doen wanneer commentaar geven.
Ik weet dat het gek klinkt, maar het is een belangrijk concept dat de meeste cursussen over het hoofd zien.
Dus ik raad je ten zeerste aan om hier overheen te lezen.
Ik zal ernaar linken in de bronnen en ik zie je in de volgende video.