[Powered by Google Translate] In deze video bespreken we code-stijl, dat is iets dat is nabij en dierbaar mijn hart. Stijl beschrijft hoe uw code wordt geformatteerd, dat is onafhankelijk van wat de code eigenlijk doet. Niet alleen zal een goede stijl krijg je een betere rang in CS50, maar het zal ook helpen bij het schrijven code die veel meer leesbaar en onderhouden, dat aan het eind van de dag, gaat om uw leven een stuk eenvoudiger te maken. 

De drie belangrijkste onderdelen van de code stijl die we zullen bespreken Deze video is een commentaar, opmaak, en variabele namen. Laten we beginnen met commentaar. Vergeet niet, opmerkingen hebben geen effect op de functionaliteit van uw code. Ze dienen slechts als nuttige tips voor ons als programmeurs. Goede opmerkingen moeten beantwoorden een van de twee vragen. 

Ten eerste, wat deze blok code doen? Dit is een kort en beschrijving van de toepassing van de lijnen die volgen. Bijvoorbeeld, moet u naar de plaats waar je implementeerde een bepaalde functie naar een vast bug of iets veranderen. Zonder opmerkingen, moet u verdiepen in vele lijnen van code probeert hetzelfde te achterhalen waar die functie is. Of als het is al een paar dagen geleden dat je hebt gekeken naar een van de uw programma's, zou je niet meer weet wat een bepaalde functie of lus werkt. Dus opmerkingen zullen maken reacquainting jezelf met oude code, of kennis te maken met iemand anders code, veel soepeler. De tweede vraag een goede reactie antwoorden is waarom heb ik implementeren dit blok op deze manier? Als u code schrijft, zul je vaak nodig hebt om ontwerpbeslissingen te kunnen nemen. Moet ik gebruik maken van een while-lus of een for-lus hier? Moet ik dit blok code te maken in een aparte functie? Met behulp van opmerkingen kunt u documenteren uw ontwerp beslissingen, waardoor uw code gemakkelijker te begrijpen voor anderen, kan die zich afvragen exact dezelfde ontwerp vragen als ze lezen uw code. Of zelfs jezelf, als je terug naar een blok van code na enige tijd. 

In C, en de andere talen we zullen zien in CS50, zijn er twee manieren om commentaar toe te voegen aan uw code, in-line comments en multi-line commentaar. In-line opmerkingen zijn zeer geschikt voor het documenteren van stukken code in functies. Bijvoorbeeld kan een in-line geplaatst beschrijven doel van een for-lus of een hoek zaak die noodzakelijk een voorwaarde. Multi-line opmerkingen zijn zeer geschikt voor het documenteren van functies. Wanneer u een functie te schrijven, moet je altijd, altijd, altijd documenteren wat het doet met een reactie. Hieronder vallen welke de ingangen voor de functie zijn, wat de output van de functie, en misschien waarom de functie geïmplementeerd als dat het. Wanneer u een functie handtekening te wijzigen, gaat u terug waarde, of de uitvoering, is het belangrijk om ook een update van de bijbehorende documentatie commentaar. Een mismatch tussen reactie van een functie en implementatie kan echt verwarrend voor lezers. Ook het creëren van een multi-line commentaar op de top van elk. c of. h bestand dat u schrijft, beschrijft wat de bestand niet, is ook een zeer goed idee. 

Als je commentaar uw code, een van de eerste vragen die je misschien is, nou ja, hoeveel moet ik commentaar mijn code? Het is vaak niet nodig om aan te tonen elke een regel code. Bijvoorbeeld, een lijn die zegt int x = 5 heeft geen behoefte aan een zei er wel eens die zegt "ingesteld x tot 5". Niet commentaar genoeg, hoewel, zoals we hebben gezien, kan het begrijpen van uw code erg moeilijk. Dus een goede vuistregel is om te reageren interessant blokken van code, waarbij een blok bestaat uit een paar verwante lijnen. 

Dus laten we eens kijken naar een voorbeeld. Hier is een niet-commentaar C functie. Oke, aangezien dit een functie, het eerste wat we nodig hebben om toe te voegen is een reactie uit te leggen wat de functie-ingangen zijn en wat het doet. Dus voegen we een multi-line commentaar. Geweldig. Nu weten we precies wat onze functie doet. Laten we nu een aantal in-line commentaar. We kunnen verdelen onze code in twee blokken van dezelfde lijnen. Lijnen 4 en 5 construct strings gebaseerd op de input en lijnen 6 tot en met 9-uitgang die strings binnen songteksten. Dus laten we aantonen dat met commentaar. Awesome. Nu onze functie is commentaar. 

Merk op dat onze in-line commentaar niet hoeven te gebruiken compleet zinnen of eindigen met een punt. Het is belangrijk dat er een ruimte tussen de tweede schuine streep en het begin van de reactie. Dit is de frequentie van opmerkingen binnen uw programma's dat je moet schieten voor. Let hier op de manier waarop we de twee blokken van gerelateerde code gescheiden binnenkant van onze koor functie met een extra carriage return. 

Dit brengt ons bij het volgende onderdeel van de code stijl, formatteren. Toen ik voor het eerst de programmering begonnen, ik raakte de Enter sleutel zeer zelden, wat resulteerde in gigantische, onleesbaar blobs van de code. Ik denk dat ik eigenlijk mijn lesgeven collega beledigd, omdat ze was niet al te blij met me. Visueel groeperen blokken van gerelateerde code, met behulp van vervoer rendementen, kan uw code gemakkelijker om duidelijk romen en af te bakenen welke regels code uw opmerkingen zijn uit te leggen. Dat gezegd zijnde, het verspreiden van uw code te veel, net als bij twee of meer lijnen tussen code blokken of functies, kan maken het ook veel minder leesbaar. 

Inspringen is een ander belangrijk aspect van de code-formaat. Altijd, altijd, altijd streepje het lichaam van een functie, lus, of aandoening. Dit maakt duidelijk dat regels code zijn in een lus, bijvoorbeeld, en die coderegels zijn daarbuiten. CS50 raadt u inspringen met vier ruimtes, maar als u kiest voor iets anders, moet u consequent in uw code. Op deze nota, CS50 adviseert u beugel plaatsen op hun eigen lijn. Op die manier zal steunen visueel line-up op dezelfde links marge, dus het glashelder is waar een blok begint en eindigt. Echter, het is ook goed om beugels te plaatsen op dezelfde lijn als een voorwaarde, bijvoorbeeld om ruimte te besparen. Als u dit doet, hoewel, zorg ervoor dat u een spatie voor de accolade dus het is niet naast een afsluitende smooshed haakje of een woord. 

Wat u ook kiest, het belangrijkste is zijn om consequent door uw code. Wat we niet willen zien, is echter ingesprongen accolades. Hierdoor maakt de beugels lijken losgekoppeld van de conditie, lus, of functie ze afbakenen, waardoor de code moeilijk te lezen. In C en de andere talen we zullen zien, accolades zijn optioneel voor enkele lijn voorwaarden of lussen. Het is fijn om accolades weglaten in dit geval, maar als u dit doet, moet u consequent in uw code. 

Bij het definiëren van functies, CS50 raadt je schrijft het terug type van de functie op dezelfde lijn als de naam van de functie. Echter, het is ook op OK om het return type schrijven op zijn eigen lijn, die kan maken functiedefinities gemakkelijker te vinden in wat tekst editors. 

Tot slot, zorg ervoor dat spaties rond trefwoorden en exploitanten. Bijvoorbeeld, een lijn die zegt int x = 5 is veel gemakkelijker te lezen als er spaties rond de gelijk-teken. Ook, zorg ervoor dat je een spatie na zoekwoorden vinden als, voor en tijdens. Zonder een ruimte, kunnen deze eruit functie-aanroepen, waarvan zij geen. 

Dus laten we eens kijken naar een voorbeeld van de toepassing van goede stijl een slecht opgemaakte blok code. Oke, laten we beginnen vanaf de top. We kunnen zien dat de opening brace van de belangrijkste is op dezelfde lijn als naam van de functie. Als we dit gaan doen, moet er een ruimte tussen het sluiten haakje en de brace, zoals dit. Echter, CS50 adviseert beugels staan op hun eigen lijn. Dus laten we dat doen. Nu we in het lichaam van de hoofdfunctie, moeten we om te beginnen met inspringen code, we zullen gebruik maken van de aanbevolen vier ruimten. Vervolgens zien we dat er geen ruimte rond het gelijkteken hier, dus laten we aan toevoegen dat. Hier zien we dat er geen ruimte is tussen de if en de geopend haakje, dus laten we aan toevoegen dat, samen met enkele ruimte rond het groter dan teken. Opnieuw zien we dat er geen ruimte tussen de sluiting haakje en de opening brace hier. Als we gaan deze op dezelfde lijn, moet er een spatie voor de accolade. Echter, het lijkt erop dat het lichaam van onze Voorwaarde is slechts een regel. Dus we hoeven niet aan de beugels op alle op te nemen. We moeten nu zeker laten inspringen zijn op het lichaam van elk van onze voorwaarden. We zijn zeker niet wilt dat deze laatste regel te worden op dezelfde lijn als anders, dus laten we druk op Enter en streepje. Tot slot, om de gesloten accolade voor de belangrijkste behoeften op een aparte regel. 

We kunnen hier zien we twee verschillende blokken gerelateerde code. Lijnen 4 tot en met 6 vraagt ​​de gebruiker om invoer en de resterende lijnen geven die ingang voor de gebruiker. Dus is het zinvol om wat ruimte zetten tussen deze twee blokken voor de duidelijkheid. En daar gaan we, nu deze code is veel gemakkelijker te lezen met goede stijl. 

Tot slot, laten we praten over onze derde component van goede stijl: variabele namen. Uw variabele namen moeten beschrijven waarde die zij vertegenwoordigen. Laten we opnieuw ons eerdere voorbeeld. Flessen is een goede beschrijvende naam voor de variabele die aangeeft hoeveel flessen links op de muur. Namen als x of numBots zijn niet erg beschrijvend en zijn niet goed voor de leesbaarheid van de code. Terwijl variabelen genoemd door een enkele letter komen vaak voor bij wiskunde en andere gebieden, kunnen ze de code heel hard begrijpen. De uitzondering op deze regel is iterator variabelen in lussen. In voor loops, bijvoorbeeld, het is fijn om te gebruiken variabele namen als i, j, en k voor iteratie. Bij het maken van iterator variabelen binnen loops, het is aanbevolen dat u dit doet binnen de lus zelf, in plaats dan buiten de lus, zodat we houden variabelen scoped strak mogelijk. 

Anderzijds, als een variabele aantal flessen links op de muur is, terwijl beschrijvend, heel uitgebreide en niet nodig. In het geval u wilt een variabele te maken met meerdere woorden, scheiden die woorden met streepjes. Bijvoorbeeld, is_ready is veel beter leesbaar dan isReady. Het is fijn om meerdere variabelen te verklaren op dezelfde lijn. Echter, als u dat doet, niet initialiseren sommige variabelen, maar anderen niet. Dat betekent zoiets als int dubbeltjes, stuivers puntkomma, is OK. Maar int dubbeltjes = 0, penningen puntkomma is dat niet. 

Tot slot, bij het declareren van pointers, is het aanbevolen dat u de asterisk naast de aanwijzer type, niet de naam van de variabele. Dus int * p is aan te bevelen in plaats van int ruimte * p. Whoo! Dus dat lijkt een hoop regels te herinneren, maar maak je geen zorgen. Als er ooit in twijfel, aarzel dan niet om te verwijzen naar CS50's online stijlgids. 

Laten we snel de belangrijke samen te vatten punten van de code stijl. Ten eerste, comment code. Altijd, altijd, altijd beschrijven wat functies uit te voeren met een multi-line commentaar en opmerkingen om de paar lijnen van code in-line. Tweede. Wees consistent met uw code opmaak. Besteed aandacht aan uw plaatsing en het gebruik van braces alsmede ruimte rond zoekwoorden en exploitanten. Tot slot kiest u beschrijvende namen van variabelen. Variabelen moeten beschrijven de waarde die ze vertegenwoordigen, maar mag niet voor altijd nemen u te typen. 

En dat is het. Dit alles zal al snel een tweede natuur geworden zoals u schrijven meer en meer code, en u zult worden codering met stijl in een mum van tijd. Mijn naam is Tommy, en dit is CS50.