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