[Powered by Google Translate] En ĉi tiu video, ni diskutos kodo stilo, kiu estas iu kiu estas proksime kaj kara al mia koro. Stilo priskribas kiel via kodo estas formatita, kio estas sendependa de tio, kion la kodo efektive faras. Ne nur bona stilo iru pli bonan rangon en CS50, sed ankaŭ helpos vin skribi kodon kiu estas multe pli legebla kaj maintainable, kiu, ĉe la fino de la tago, tuj faros vian vivon multe pli facila. 

La tri ĉefaj komponantoj de kodo stilo kiu ni diskutos ĉi tiu video estas komentoj, formatado, kaj variabloj nomoj. Ni komencu per komentoj. Memoru, komentoj ne havas efikon sur la funcionalidad de via kodo. Ili nur servas kiel utila aludoj al ni kiel programistoj. Bonan komentoj devus respondi unu el du demandojn. 

Unue, kion signifas ĉi tiu bloko de kodo fari? Tio estas mallonga kaj dolĉa priskribo de la celo de la linioj kiuj sekvas. Ekzemple, vi eble bezonas trovi la lokon, kie vi implementado aparta karakterizaĵo ripari cimo aŭ ŝanĝo ion. Sen komentoj, vi eble bezonas poro super multaj linioj de kodo por provi elkompreni precize kie tiu karakterizaĵo estas. Aŭ se jam pasis kelkaj tagoj ekde vi jam rigardis unu el viaj programoj, vi eble ne memoras, kion aparta funkcio aŭ buklo faras. Do komentoj faros reacquainting vin per malnova kodo, aŭ konatigi vin kun iu alia estas kodo, multe pli milda. La dua demando estas bona komento respondojn Tial faris mi apliki ĉi tiu bloko en tiu maniero? Kiel vi skribas kodo, vi ofte bezonas fari dezajno decidoj. Ĉu mi uzas dum buklo aŭ por buklo tie? Ĉu mi faras ĉi tiun blokon de kodo en aparta funkcio? Uzanta komentojn, vi povas dokumenti viajn dezajno decidoj, kiuj faros vian kodon pli facile kompreni por aliaj, kiuj povas esti demandante la ĝusta sama dezajno demandoj dum ili legas vian kodon. Aŭ eĉ mem, se vi revenos al bloko de kodo post iu periodo de tempo. 

En C, kaj la aliaj lingvoj ni vidos en CS50 esas du manieroj de aldoni komentojn al via kodo, en linio komentoj kaj plurliniaj komentoj. En-linio komentoj estas granda por dokumenti pecoj de kodo ene funkcioj. Ekzemple, en-linio komento povus priskribi la celo de a por buklo aŭ angulo kazo ke postulas kondiĉo. Plurliniaj komentoj estas granda por dokumenti funkcioj. Kiam ajn vi skribos funkcio, vi devus ĉiam, ĉiam, ĉiam dokumenti kio faras kun komento. Tio inkluzivas kion la enigoj por la funkcio estas, kion la eligo de la funkcio estas, kaj eble kial la funkcio estas implementado en la vojo, kiun ĝi estas. Kiam ajn vi ŝanĝas funkcio de signumo, reveni valoro, aŭ ekzekuto, estas grave ankaŭ ĝisdatigi la responda dokumentado komento. Al mismatch inter funkcio la komento kaj efektivigo povas esti vere konfuza por legantoj. Simile, kreante plurliniaj komentoj en la supro de ĉiu. c aŭ. h dosiero kiun vi skribas, priskribas kion la dosiero ne, estas ankaŭ tre bona ideo. 

Kiel vi diris, via kodo, unu el la unuaj demandoj vi eble estas, nu, kiom mi devas diri mian kodo? Estas ofte nenecesa dokumenti ĉiu sola linio de kodo. Ekzemple, linio kiu diras int x = 5 ne bezonas komenti pri ĝi kiu diras "starigis x al 5". Ne dirante sufiĉa, kvankam, kiel ni vidis, povas fari kompreni vian kodon tre malfacila. Do bonan regulo estas diri interesa blokoj de kodo, kie bloko konsistas el kelkaj rilatantaj linioj. 

Do ni rigardu ekzemplon. Jen uncommented C funkcio. Konsentite, ekde ĉi estas funkcio, la unua afero kiun ni bezonas aldoni estas komenton klarigante kion la funkcia enigoj estas kaj kion ĝi faras. Do ni aldonu plurliniaj komentoj. Granda. Nun ni scias precize kion nia funkcio faras. Ni aldonu kelkajn en linio komentoj nun. Ni povas dividi niajn kodon en du blokoj de similaj linioj. Linioj 4 kaj 5 konstruo kordoj bazita sur la enigo kaj linioj 6 tra 9 eligo tiuj kordoj ene song lyrics. Do estu la dokumenti ke kun komentoj. Awesome. Nun nia funkcio estas dirita. 

Rimarku ke nia en-linio komentojn ne bezonas uzi kompleta frazojn aŭ fino kun periodo. Estas grava ke estas spaco inter la dua oblikvo kaj la komenco de la komento. Ĉi tiu estas la ofteco de komentoj inter viaj programoj ke vi devus pafi por. Rimarku tie kiel ni disigis la du blokoj de rilataj kodo ene de nia ĥoro funkcio kun ekstra tirilo. 

Ĉi alportas nin al la sekva komponanto de kodo stilo, strukturado. Kiam mi unue komencis programadon, mi batis la Entajpu klavo tre malofte, kiu rezultis en gigante, nelegebla _blobs_ de kodo. Mi kredas ke mi efektive ofendis mian instruon ulo, pro tio ke ne estis tro feliĉa kun mi. Vide kolektante blokoj de rilataj kodo, uzante kaleŝo revenas, povas fari viajn kodo facile skim kaj klare delinear kiuj linioj de kodo viaj komentoj estas klarigoj. Ke oni diras, etendis viajn kodo tro multe, kiel kun du aŭ pli linioj inter kodo blokoj aŭ funkcioj, povas ankaŭ faras ĝin multe malpli legebla. 

Deŝovon estas alia grava aspekto de kodo formato. Ĉiam, ĉiam, ĉiam indent la korpo de funkcio, buklo, aŭ kondiĉo. Tio igas ĝin klara kiu linioj de kodo estas ene buklo, ekzemple, kaj kies linioj de kodo estas ekstere de tiu. CS50 rekomendas ke vi indent kun kvar spacoj, sed se vi elektos ion alian, esti certa al esti konsekvenca viaj kodo. En tiu mesagxo, CS50 rekomendas ke vi metu krampoj sur siaj propra linio. Tiel, krampoj vicigas vide al la sama maldekstra rando, tial ĝi estas kristalo certe kie bloko komencas kaj finiĝas. Tamen, ĝi estas ankaŭ bone meti krampoj en la sama linio kiel kondiĉo, ekzemple, por konservi spacon. Se vi faros tion, kvankam, certigu vin inkluzivas spaco antaŭ la frizita streĉa do ĝi ne smooshed apud fermo paren aŭ vorto. 

Kiu ajn vi elektas, la plej grava afero estas esti konsekvenca en viaj kodo. Kion ni ne volas vidi, tamen, estas dentado frizita krampoj. Farante tiel faras la krampoj aperas malkonektita de la kondiĉo, iteracio, aŭ funkcio ili estas Marki, farante la kodo malfacile legebla. En C kaj aliaj lingvoj ni vidos, frizita krampoj estas nedeviga por sola linio kondiĉoj aŭ cikloj. Ĝi estas bone preterlasi frizita krampoj en ĉi tiu kazo, sed se vi tiele, esti certa al esti konsekvenca viaj kodo. 

Kiam difinanta funkcioj, CS50 rekomendas ke vi skribas la revenu tipo de la funkcio sur la sama linio kiel la nomo de la funkcio. Tamen, ĝi estas ankaŭ bone skribi la reveno tipo en lia propra linio, kiu povas fari funkcio difinoj pli facile trovi en iuj teksto redaktiloj. 

Fine, nepre inkluzivi spacoj ĉirkaŭ ŝlosilvortoj kaj operatoroj. Ekzemple, linio kiu diras int x = 5 estas multe pli facile legu se estas spacoj ĉirkaŭ la egalsigno. Simile, certigu ke vi havas spacon post ŝlosilvortoj kiel se, por, kaj tempo. Sen spaco, tiuj povus aspekti kiel funkcio alvokoj, kion ili ne estas. 

Do ni rigardu ekzemplon de aplikanta bona stilo al malbone formatan bloko de kodo. Konsentite, ni komencu de la supro. Ni povas vidi ke la malfermo de streĉa de ĉefaj estas sur la sama linio kiel la funkcia nomo. Se ni faros tion, tie devas esti interspaco inter la fermo paren kaj la krampoj, kiel ĉi tio. Tamen, CS50 rekomendas ke krampoj staras sur siaj propra linio. Do ni faru tion. Nun ke ni estas en la korpo de la ĉefa funkcio, ni bezonos komenci indenting kodo, ni uzos la rekomendis kvar spacoj. Poste, ni vidas ke ne estas spaco ĉirkaŭ la egala signo ĉi tie, do ni aldonu, ke. Tie, ni vidas ke ne estas spaco inter la se kaj la malfermita paren, do ni aldonu, ke, kune kun iuj spaco ĉirkaŭ la pli granda ol signo. Denove, ni vidas ke ne estas spaco inter la fermo paren kaj la malfermo streĉa tie. Se ni iras meti tiujn en la sama linio, ne bezonas esti interspaco antaŭ la frizita streĉa. Tamen, ĝi aspektas kiel la korpo de niaj kondiĉo estas nur unu linion. Do ni ne bezonas inkluzivi la streĉaj ajn. Ni nun bezonas esti nepre indent en la korpo de ĉiu el niaj kondiĉoj. Ni definitive ne deziras ĉi lasta linio al esti sur la sama linio kiel alian, do ni sukceson Eniru kaj indent. Fine, la fermo frizita streĉa por ĉefa bezonoj esti en lia propra linio. 

Ni povas vidi ĉi tie ni havas du malsamajn blokoj de rilataj kodo. Linioj 4 tra 6 instigas la uzanton por eniro kaj la ceteraj linioj montras ke enigo al la uzanto. Do logike meti iun spacon inter tiuj du blokoj por klareco. Kaj ni iros, nun ĉi tiu kodo estas multe pli facile legi kun bonan stilon. 

Fine, ni parolu pri nia tria komponanto de bona stilo: variablo nomoj. Via variablo nomoj devus priskribi la valoro, ke ili reprezentas. Ni reviziti nia pli frua ekzemplo. Boteloj estas bona priskriba nomo por la variablo kiu reprezentas kiom boteloj lasis sur la muro. Nomoj kiel x aŭ numBots ne estas tre priskriba kaj estas ne estas bona por la legibilidad de via kodo. Dum variabloj enoficigita de sola litero estas komuna en math kaj aliaj kampoj, ili povas fari viajn kodo tre malmola kompreni. La escepto al tiu regulo estas iterator variabloj ene maŝojn. In por bukloj, ekzemple, estas fajna uzi variablon nomojn kiel i, j, kaj k por ripeto. Kiam kreante iterator variabloj ene bukloj, estas rekomendis ke vi faras tion ene de la buklo mem, prefere ol ekstere de la ciklo, tiel ke ni povu konservi variabloj kiel firme scoped ebla. 

Aliflanke, variablo nomon kiel numero de boteloj lasis sur la muro estas, dum priskriba, tro abundajn kaj ne necesa. En la evento vi volas krei variablo kun multnombraj vortoj, apartigi tiujn vortojn kun substrekoj. Ekzemple, is_ready estas multe pli legebla ol isReady. Ĝi estas bone por deklari multnombraj variabloj en la sama linio. Tamen, se vi faras tion, mi ne pravalorizi iuj variabloj sed ne aliaj. Tio signifas ion kiel int dimes, cendoj punktokomo, estas bone. Sed int dimes = 0, cendoj punktokomo estas ne. 

Fine, kiam deklarante punteros, ĝi estas rekomendita ke vi metas la asteriskon apud la puntero de tipo, ne la nomo de la variablo. Do int * p rekomendas anstataŭ int spaco * p. Whoo! Por ke similas multajn regulojn por memori, sed ne maltrankvilu. Se iam en dubo, ne hezitu raporti al CS50 la linio stilo gvidas. 

Ni rapide resumi la grava punktoj de kodo stilo. Unue, komenti vian kodon. Ĉiam, ĉiam, ĉiam priskribi kion funkcioj fari kun plurliniaj komentoj kaj komenti ĉiu malmultaj linioj de kodo en linio. Dua. Esti konsekvenca kun via kodo strukturado. Atentu viajn lokigo kaj uzado de streĉaj tiel kiel Interspacigo ĉirkaŭ ŝlosilvortoj kaj operatoroj. Fine, elektu priskriba variablo nomoj. Variabloj devus priskribi la valoro kiun ili reprezentas, sed ne devus preni vin por ĉiam por tajpi. 

Kaj tio estas ĝi. Ĉio ĉi rapide fariĝis dua naturo kiel vi skribi pli kaj pli kodo, kaj vi estos kodigo kun stilo en neniu tempo. Mia nomo estas Tommy, kaj ĉi tiu estas CS50.