[Powered by Google Translate] I denne videoen vil vi diskutere kode stil, som er noe
som er nære og kjære til mitt hjerte.
Stil beskriver hvordan koden er formatert, som er
uavhengig av hva koden faktisk gjør.
Ikke bare vil god stil får du en bedre karakter i CS50,
men det vil også hjelpe deg med å skrive kode som er mye mer
lesbart og vedlikeholdsvennlig, som på slutten av dagen,
kommer til å gjøre livet mye enklere.
>> De tre viktigste komponentene i koden stil som vi vil diskutere
denne videoen er kommentarer, formatering,
og variabel navn.
La oss starte med kommentarer.
Husk kommentarene har ingen effekt på
funksjonalitet av koden din.
De bare tjene som nyttige tips til oss som programmerere.
Gode ​​kommentarer bør svare på ett av to spørsmål.
>> Først, hva denne blokken med kode gjør?
Dette er en kort og konsis beskrivelse av hensikten med
linjene som følger.
For eksempel må du kanskje finne stedet hvor du
implementert en bestemt funksjon for å fikse en
bug eller endre noe.
Uten kommentarer, må du kanskje pore over mange linjer
kode prøver å finne ut nøyaktig hvor denne funksjonen er.
Eller hvis det har vært et par dager siden du har sett på en av
programmene, kan du ikke huske hva en bestemt
funksjon eller sløyfe gjør.
Så kommentarer vil gjøre reacquainting selv med
gamle koden, eller acquainting deg selv med en annens
kode, mye jevnere.
Det andre spørsmålet en god kommentar svar er hvorfor jeg
implementere denne blokken på denne måten?
Som du skriver kode, vil du ofte trenger
å ta raske beslutninger.
Bør jeg bruke en stund løkke eller en for loop her?
Bør jeg gjøre denne blokken med kode i en egen funksjon?
Ved hjelp av kommentarer, kan du dokumentere din design
beslutninger, som vil gjøre koden lettere å forstå
for andre, som kanskje spørre seg selv nøyaktig samme
utforming spørsmål mens de leser koden.
Eller deg selv, hvis du kommer tilbake til en blokk med kode etter
viss periode.
>> I C, og de andre språkene vi ser i CS50, er
to måter å legge til kommentarer i koden, in-line kommentarer
og flere linjer kommentarer.
In-line kommentarer er stor for å dokumentere deler av koden
innenfor funksjoner.
For eksempel, kan en in-line kommentar beskrive
Formålet med en for løkke eller et hjørne sak som nødvendiggjør
en betingelse.
Multi-line kommentarer er stor for å dokumentere funksjoner.
Når du skriver en funksjon, bør du alltid, alltid,
alltid dokumentere hva det gjør med en kommentar.
Dette inkluderer det innganger til funksjonen er, hva de
utgang av funksjonen er, og kanskje derfor funksjonen er
implementert på den måten som det er.
Når du endrer en funksjon underskrift, tilbake
verdi, eller gjennomføring, er det viktig å også oppdatere
tilsvarende dokumentasjon kommentar.
En mismatch mellom en funksjons kommentar og
gjennomføring kan være veldig forvirrende for leserne.
Tilsvarende, og skaper en flerlinjet kommentar øverst
av hver. c eller. h fil du skriver, beskrive hva
Filen er også en veldig god idé.
>> Som du kommenterer koden, en av de første spørsmålene du
kan ha er, vel, hvor mye skal jeg kommentere min kode?
Det er ofte unødvendig å dokumentere hver
eneste linje med kode.
For eksempel, en linje som sier int x = 5 trenger ikke en
kommentere om det som sier "satt x to 5".
Ikke kommenterer nok, men som vi har sett, kan gjøre
forstå koden svært vanskelig.
Så en god tommelfingerregel er å kommentere interessante blokker av
kode, hvor en blokk består av et fåtall relaterte linjer.
>> Så la oss ta en titt på et eksempel.
Her er en uncommented C funksjonen.
Ok, siden dette er en funksjon, er det første vi må legge
er en kommentar som forklarer hva funksjonens innganger
er og hva den gjør.
Så la oss legge til et multi-line kommentar.
Flott.
Nå vet vi nøyaktig hva vår funksjon gjør.
La oss legge til noen in-line kommentarer nå.
Vi kan dele vår kode i to blokker av samme linjer.
Linje 4 og 5 Konstruer strenger basert på innspill og
linje 6 til 9 utgang disse
strenger i sangtekster.
Så la oss dokumentere at med kommentarer.
Awesome.
Nå vår funksjon er kommentert.
>> Legg merke til at våre in-line kommentarer ikke trenger å bruke hele
setninger eller avslutte med en periode.
Det er viktig at det er et mellomrom mellom andre skråstrek
og starten av kommentaren.
Dette er frekvensen av kommentarer i programmene dine
at du bør skyte for.
Legg merke her hvordan vi skilt de to blokkene av relatert kode
Innsiden av våre kor funksjon med en ekstra linjeskift.
>> Dette bringer oss til neste del av koden stil,
formatering.
Da jeg først begynte programmering, traff jeg på Enter
nøkkel svært sjelden, resulterte som gigantiske, uleselig
blobs av koden.
Jeg tror jeg faktisk fornærmet min undervisning kar, siden hun
var ikke så fornøyd med meg.
Visuelt gruppering blokker av relaterte kode, ved hjelp av vogn
avkastning, kan gjøre koden enklere å skumme og tydelig
avgrense hvilke linjer med kode kommentarene dine forklare.
Som blir sagt, spre ut din kode for mye, som med
to eller flere linjer mellom kodeblokker eller funksjoner, kan
også gjøre det mye mindre lesbar.
>> Innrykk er en annen viktig
aspekt av kode format.
Alltid, alltid, alltid rykke i kroppen til en funksjon, loop,
eller tilstand.
Dette gjør det klart hvilke linjer med kode er inne i en
løkke, for eksempel, og hvilke linjer med kode
er utenfor det.
CS50 anbefaler at du innrykk med fire plasser, men
hvis du velger noe annet, må du være konsekvent
hele koden din.
På dette notatet, anbefaler CS50 at du plasserer bukseseler
på sin egen linje.
På den måten vil bukseseler stille opp visuelt på samme venstre
margin, så det er krystallklart hvor en blokk begynner og slutter.
Men det er også greit å plassere bukseseler på samme linje som en
tilstand, for eksempel for å spare plass.
Hvis du gjør dette, men husk å ta en plass
før den krøllete brace så det er ikke smooshed ved siden av en avsluttende
paren eller et ord.
>> Uansett hvilken du velger, er det viktigste å være
konsekvent gjennom koden din.
Hva vi ikke ønsker å se, selv om det er
innrykket klammeparentes.
Gjør du det gjør klammeparentesene vises koblet fra
tilstand, loop, eller funksjon de demarcating, noe som gjør
koden vanskelig å lese.
I C og andre språk vil vi se, klammeparentes er
valgfritt for enslige linjeforholdene eller løkker.
Det er greit å utelate klammeparentes i dette tilfellet, men hvis
du gjør det, sørg for å være konsekvent
hele koden din.
>> Når du definerer funksjoner, anbefaler CS50 du skriver
returnere type funksjon på samme linje som navnet
funksjonen.
Men det er også OK å skrive returtypen på egen hånd
linje, som kan gjøre funksjonsdefinisjoner lettere å finne i
noen tekstredigeringsprogrammer.
>> Til slutt, sørg for å inkludere områder rundt
søkeord og operatører.
For eksempel, en linje som sier int x = 5 er mye lettere å
lese hvis det er mellomrom rundt likhetstegnet.
Tilsvarende må du ha et mellomrom etter søkeord som om,
for, og mens.
Uten en plass, kan disse se ut som funksjonskall,
som de ikke er.
>> Så la oss ta en titt på et eksempel på bruk av god stil
til en feilformatert blokk med kode.
Ok, la oss starte fra toppen.
Vi kan se at åpningen spenne av main er på samme
linje som funksjonens navn.
Hvis vi skal gjøre dette, må det være et mellomrom mellom
den avsluttende paren og spenne, som dette.
Men anbefaler CS50 at bukseseler stå
på sin egen linje.
Så la oss gjøre det.
Nå som vi er i kroppen av den viktigste funksjonen, må vi
å starte innrykk kode, vil vi bruke
anbefales fire mellomrom.
Deretter ser vi at det ikke er plass rundt likhetstegnet
her, så la oss legge til at.
Her ser vi at det ikke er noe mellomrom mellom hvis og
åpen paren, så la oss legge til at, sammen med litt plass rundt
større enn-tegn.
Igjen ser vi det ikke er plass mellom den avsluttende parentes og
åpningen spenne her.
Hvis vi kommer til å sette disse på samme linje, det må
være et mellomrom før krøllete brace.
Imidlertid ser det ut til at kroppen vår
tilstand er bare en linje.
Slik at vi ikke trenger å ta med klammene i det hele tatt.
Vi trenger nå å være sikker på å rykke på kroppen hver av
våre forhold.
Vi definitivt ikke ønsker dette siste linjen til å være på samme
linje som andre, så la oss hit Enter og innrykk.
Til slutt, til den avsluttende curly brace for viktigste behovene være på
en egen linje.
>> Vi kan se her har vi to forskjellige
blokker av relaterte kode.
Linjene 4 til 6 be brukeren om innspill og
gjenværende linjer viser at input til brukeren.
Så det er fornuftig å sette noen plass mellom disse to blokkene
for klarhet.
Og der vi går, nå denne koden er mye lettere å lese med
god stil.
>> Til slutt, la oss snakke om vår tredje del av god stil:
variabelnavn.
Dine variabelnavn skal beskrive
verdi som de representerer.
La oss se våre tidligere eksempel.
Flasker er et beskrivende navn for variabelen som
representerer hvor mange flasker som er igjen på veggen.
Navn som x eller numBots er ikke veldig beskrivende og er
ikke bra for lesbarheten av koden din.
Mens variabler navngitt av en enkelt bokstav er vanlig i
matematikk og andre felt, kan de gjøre koden veldig hardt
å forstå.
Unntaket fra denne regelen er iterator
variabler inne i løkker.
I for looper, for eksempel, er det greit å bruke variabel
navn som i, j, og k for gjentakelse.
Når du oppretter iterator variabler innenfor looper, er det
anbefales det at du gjør dette innen sløyfen selv, heller
enn utenfor loopen, slik at vi kan holde variabler som
tett scoped som mulig.
>> På den annen side, en variabel navn som antall flasker
igjen på veggen er, mens beskrivende, altfor ordrik
og ikke nødvendig.
I tilfelle vil du opprette en variabel med
flere ord, skiller disse ordene med understrek.
For eksempel er is_ready mye mer lesbart enn isReady.
Det er greit å erklære flere variabler på samme linje.
Men hvis du gjør det, ikke initialisere noen variabler, men
ikke andre.
Det betyr noe sånt som int dimes, pennies
semikolon, er OK.
Men int dimes = 0, pennies
semikolon er det ikke.
>> Til slutt, når erklære pekere, anbefales det
at du plasserer stjerne ved siden av pekeren er typen, ikke
navnet på variabelen.
Så int * p anbefales fremfor int
plass * p.
Whoo!
Så det virker som mange regler til
huske, men ikke bekymre deg.
Hvis noen gang i tvil, ikke nøl med å henvise til CS50 er
online stil guide.
>> La oss raskt oppsummere de viktige
poeng med kode-stil.
Først kommentere koden din.
Alltid, alltid, alltid beskrive hvilke funksjoner gjør
med en multi-line kommentar og kommentere noen få linjer av
kode in-line.
Sekund.
Være i samsvar med koden formatering.
Ta hensyn til plassering og bruk av bukseseler
samt avstand rundt søkeord og operatører.
Til slutt velger beskrivende variabelnavn.
Variabler skal beskrive verdien de representerer, men
bør ikke ta deg for alltid å skrive.
>> Og det er det.
Alt dette vil raskt bli andre naturen som du
skrive mer og mer kode, og du vil bli koding
med stil på et blunk.
Mitt navn er Tommy, og dette er CS50.