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