‫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.