Nyttige tips

Slik kjører du C-kode på riktig måte

Pin
Send
Share
Send
Send


Før vi skriver vårt første C ++ -program, må vi vite de grunnleggende kravene til C ++ -kode, det er ikke så mange som det kan virke ved første øyekast. Her er den faktiske listen:

  • hver kommando slutter med en semikolon ,,
  • det kan ikke være mellomrom i navnene på kommandoer og andre instruksjoner, og de kan heller ikke starte med tall,
  • C ++ er store og små bokstaver. Det vil si at CODE, CoDe og kode kan utføre helt andre oppgaver,

Dette er hovedreglene som grunnlaget for programmering i C ++ bygger på.

2. Reglene kan bli brutt hvis det er personlige innvendinger mot dem.

Dette er et forsøk på å lage et sett med generelle anbefalinger uten å pålegge en ensartet stil. Erfarne programmerere tilpasser vanligvis stilen uansett. En slik liste over anbefalte tilgjengelige (eller i det minste et krav for å bli kjent med den) får folk til å tenke på programmeringsstilen og evaluere sin egen praksis på dette området.

Nybegynnere og uerfarne programmerere bruker derimot vanligvis stilretningslinjer for å bedre forstå programmerernes sjargong.

9. Forkortelser og forkortelser for navn må være små bokstaver.

Bruk av store bokstaver kan føre til en navnekonflikt som beskrevet ovenfor. Ellers vil variablene ha navnene dVD, hTML osv., Som ikke er lesbar. Et annet problem er allerede beskrevet ovenfor, når navnet er assosiert med et annet, reduseres lesbarheten, ordet som følger forkortelsen skiller seg ikke ut som det skal.

11. Medlemmer av klassen med den private modifikatoren skal tildeles suffiks-understrekningen.

Bortsett fra navn og type, er omfang den viktigste egenskapen til en variabel. Å eksplisitt å spesifisere en tilgangsmodifiserer som understrekning eliminerer forvirringen mellom klassemedlemmer og lokale variabler. Dette er viktig fordi klassevariabler er viktigere enn variabler i metoder, og bør behandles mer nøye.

En ekstra effekt av understrekningssuffikset er å løse navneproblemet i metoder som setter verdier, så vel som i konstruktører:

Problemet er at det er to alternativer for understreking - i form av et suffiks og i form av et prefiks. Begge alternativene er mye brukt, men det første alternativet anbefales, fordi det gir bedre lesbarhet. Det skal bemerkes at definisjonen av tilgangsmodifiserer for variabler noen ganger er et viktig punkt. Selv om det ser ut til at den anbefalte praksisen er å skaffe supportere og bli mer vanlig blant fagfolk.

12. Tilpassede variabler bør gis samme navn som deres type.

void setTopic (Emne * emne) // IKKE: void setTopic (Emne * verdi)
// IKKE: ugyldig setTopic (Emne * aTopic)
// IKKE: ugyldig setTopic (Emne * t)

void connect (Database * database) // IKKE: void connect (Database * db)
// IKKE: void connect (Database * oracleDB)

Reduser kompleksiteten ved å redusere antall brukte termer og navn. Forenkler også typegjenkjenning bare med variabelenavn.

Hvis denne anbefalingen av en eller annen grunn virker upassende, betyr det at typenavnet er valgt feil.

Ikke-tilpassede variabler kan navngis etter deres formål og type:

14. Variabler med stort omfang skal kalles lange navn, med et lite omfang - kort.

Navnene på midlertidige variabler som brukes til å lagre midlertidige verdier eller indekser er best gjort korte. En programmerer som leser slike variabler, skal kunne anta at verdiene deres ikke brukes utenfor flere kodelinjer. Vanligvis er dette variablene i, j, k, l, m, n (for heltall), så vel som c og d (for tegn).

31. Konstanter i oppregninger kan ha et prefiks - et vanlig type navn.

Dette gir ytterligere informasjon om hvor erklæringen ligger, hvilke konstanter som er beskrevet i en liste, og også hva konseptkonstanter er.

En annen tilnærming er å ringe konstanter i henhold til deres vanlige type: Color :: RED, Airline :: AIR_FRANCE, etc.

Legg merke til at oppregningsnavnet vanligvis er entall, for eksempel: enum Color <. >. Flertallets navn ser bra ut når det annonseres, men er ikke godt egnet for praktisk bruk.

39. Ufullstendigheten til ødelagte linjer bør være åpenbar.

totalSum = a + b + c +
d + e

funksjon (param1, param2,
param3),

setText ("Lang linjesplitt"
"i to deler."),

for (int tableNo = 0, tableNo

Et linjeskift vises når 80 kolonnegrensen beskrevet ovenfor er overtrådt. Det er vanskelig å gi strenge oppdelingsregler, men eksemplene over viser generelle prinsipper.

  • desimaltall
  • pause etter operatøren,
  • juster en ny linje med begynnelsen av uttrykket på forrige linje.

Rom og innrykk

Separate seler med mellomrom:

Plasser mellom operatører og operander:

Når linjen blir lengre enn 100 tegn, del den i to, lag en ny linje etter utsagnet, og fortsett å skrive:

Legg igjen tomme linjer mellom funksjoner og mellom uttrykksgrupper:

49. Klassevariabler skal ikke deklareres som offentlige.

Disse variablene bryter prinsippene for skjul av informasjon og innkapsling. Bruk i stedet variabler med den private modifisereren og de tilhørende tilgangsfunksjonene. Et unntak er en klasse uten atferd, praktisk talt en datastruktur (tilsvarer C-språkstrukturer). I dette tilfellet gir det ingen mening å skjule disse variablene.

Vær oppmerksom på at strukturene i C ++ bare er stående for kompatibilitet med C, fordi bruken demper kodens lesbarhet. Bruk klasser i stedet for strukturer.

53. Implisitte sammenligninger av boolske (logiske) variabler og pekere med null bør unngås.

C ++ -standarden garanterer ikke at verdier av int- og flytevariabler lik null blir representert som binær 0. Også med en eksplisitt sammenligning er den sammenlignede typen synlig.

Det ville være logisk å anta at pekere heller ikke implisitt skal sammenlignes med null, for eksempel hvis (linje == 0) i stedet for hvis (linje). Det siste er en veldig vanlig praksis i C / C ++, så den kan også brukes.

57. Gjør-mens-løkker kan unngås.

Slike sykluser er mindre leselige fordi tilstanden er beskrevet etter kroppen. Leseren må se gjennom hele syklusen for å forstå arbeidet sitt.

Loop-gjør-mens er ikke en absolutt nødvendighet i det hele tatt. Enhver slik sløyfe kan erstattes med en stund eller for sløyfe.

Færre design bruker forbedrer lesbarheten.

61. Unngå komplekse fangstsetninger strengt tatt. Angi boolske variabler i stedet.

bool isFinished = (elementNo maxElement),
bool isRepeatedEntry = elementNo == lastElement,
if (isFinished || isRepeatedEntry) <
:
>

// IKKE:
if ((elementNo maxElement) ||
elementNo == lastElement) <
:
>

Innstilling av boolske variabler for uttrykk vil føre til selvdokumentasjon av programmet. Designet vil være lettere å lese, feilsøke og vedlikeholde.

66. Flytende punktkonstanter skal skrives med et desimal og med minst ett desimal.

dobbel total = 0,0, // IKKE ANBEFALT: dobbel total = 0,
dobbel hastighet = 3.0e8, // IKKE ANBEFALT: dobbel hastighet = 3e8,

dobbelt sum,
:
summen = (a + b) * 10,0,

Dette vektlegger ulike tilnærminger når du arbeider med heltall og flytende punktum. Fra matematisk synspunkt er disse to modellene helt forskjellige og ikke kompatible.

Og også (som vist i det siste eksemplet over) er vektleggingen lagt til typen variabel (sum) på et sted hvor dette ikke er åpenbart.

72. Kodeblokker skal utformes som vist i eksempel 1 (anbefalt) eller i eksempel 2, men ikke i noe tilfelle ikke som vist i eksempel 3. Utformingen av funksjoner og klasser skal følge eksempel 2.

mens (! gjort) <
gjøre noe (),
gjort = moreToDo (),
>

mens (! ferdig)
<
gjøre noe (),
gjort = moreToDo (),
>

mens (! ferdig)
<
gjøre noe (),
gjort = moreToDo (),
>

Eksempel 3 bruker ekstra marginer, som forhindrer en tydelig visning av den logiske strukturen til koden.

75. If-else-konstruksjonen bør struktureres som følger:

if (tilstand) <
uttalelser,
>

if (tilstand) <
uttalelser,
>
ellers <
uttalelser,
>

if (tilstand) <
uttalelser,
>
annet hvis (tilstand) <
uttalelser,
>
ellers <
uttalelser,
>

Følg av regelen over. Det er dessuten ikke forbudt å skrive annet på samme linje der den første blokkeringen av den første blokken er:

Det er bedre å plassere hver del av if-else på en egen linje. Dette forenkler kodeoperasjoner, for eksempel å flytte den andre blokken.

80. Bryteren skal utformes som følger:

bryter (tilstand) <
sak ABC:
uttalelser,
// Mangler "pause"

sak DEF:
uttalelser,
bryte,

sak XYZ:
uttalelser,
bryte,

Legg merke til at hvert enkelt ordord er innrykket i forhold til hele konstruksjonen, noe som er med på å fremheve det. Legg også merke til mellomrommene før kolonene. Hvis søkeordet for pausen mangler et sted, bør en kommentar fungere som en advarsel. Programmerere glemmer ofte å si dette ordet, så saken om bevisst unnlatelse bør beskrives spesifikt.

84. Gap

  • Operatører skal kastes med mellomrom.
  • Etter reserverte C ++ nøkkelord, bør det gis et mellomrom.
  • Du må plassere mellomrom etter komma.
  • Kolonene skal kastes med mellomrom.
  • Etter semikolonene i for-loopen, bør du plassere mellomrom.

a = (b + c) * d, // IKKE ANBEFALT: a = (b + c) * d

mens (sant) // IKKE ANBEFALT: mens (sant)
<
.

doSomething (a, b, c, d), // IKKE ANBEFALT: doSomething (a, b, c, d),

sak 100: // IKKE ANBEFALT: sak 100:

Fremhever individuelle deler av uttrykk. Forbedrer lesbarheten. Det er vanskelig å gi et omfattende sett med anbefalinger angående mellomrom i C ++. Anbefalingene over skal vise generelle prinsipper.

85. Et mellomrom kan følge et metodenavn hvis et annet navn følger.

Merk enkeltnavn. Forbedrer lesbarheten. Hvis det ikke er noe ytterligere navn, kan du utelate plassen (doSomething ()).

En annen tilnærming er å spesifisere et mellomrom umiddelbart etter åpnings parentesen. De som bruker det, legger også vanligvis et mellomrom foran lukkebraketten: doSomething (currentFile),. Dette lar deg fremheve individuelle navn, mellomrommet før lukkebraketten ser unaturlig ut, men uten det ser uttrykket asymmetrisk ut (doSomething (currentFile),).

89. Bruk justering uansett hvor det forbedrer lesbarheten.

hvis (a == lowValue) compueSomething (),
ellers hvis (a == mediumValue) beregneSomethingElse (),
ellers hvis (a == highValue) beregneSomethingElseYet (),

verdi = (potensiell * oljedensitet) / konstant1 +
(dybde * vanntetthet) / konstant2 +
(zCoordinateValue * gasDensity) / constant3,

minPosition = beregne motstand (min, x, y, z),
gjennomsnittPosisjon = beregne motstand (gjennomsnitt, x, y, z),

bryter (verdi) <
sak PHASE_OIL: strcpy (fase, "Olje"), pause,
sak PHASE_WATER: strcpy (fase, "vann"), pause,
sak PHASE_GAS: strcpy (fase, "Gass"), pause,
>

Det er mange tilfeller der koden kan justeres ytterligere, selv om den bryter reglene som er opprettet tidligere.

94. Kommentarer til klasser og metodeoverskrifter skal komme i samsvar med JavaDoc-konvensjonene.

Java-programmerere bruker en mer utviklet tilnærming til dokumentasjon på grunn av det automatiserte standardverktøyet Javadoc, som er en del av utviklingspakken og lar deg automatisk lage dokumentasjon i HTML-format fra kommentarer i kode.

Det er lignende verktøy i C ++. De følger de samme tagg-syntakskonvensjonene som JavaDoc (se for eksempel Doc ++ eller Doxygen).

Navn og variabler

Gi variablene beskrivende navn som fornavn eller hjemmelekser. Unngå navn med en bokstav som x eller c, bortsett fra iteratorer som i.

Navn på variabler og funksjoner ved hjelp av kamelregisteret. Ring klassene PascalRegister, og konstantene i UPPER_REG. Du kan lære mer om kamelkasse i denne artikkelen.

Hvis en variabel bare brukes i en spesifikk if, så gjør den lokal ved å deklarere i den samme kodeblokken, ikke global.

SmartDec, Moskva, fra 60 000 til 250 000 ₽

Velg riktig datatype for variablene dine. Hvis variabelen bare inneholder heltall, definerer du den som int, ikke dobbel.

Bruk en tekststreng som er standard for C ++, ikke C. C ++ forveksler med det faktum at den har to typer tekststrenger: strengklassen fra C ++ og den gamle char * (rekke tegn) fra C:

Hvis en bestemt konstant ofte brukes i koden din, utpeker den som const og referer alltid til denne konstanten, ikke dens verdi:

Ikke erklær en mutabel global variabel. Globale variabler skal bare være konstanter. I stedet for å gjøre verdien global, gjør den til en parameter og returnerer verdien når det er nødvendig:

C ++ grunnleggende uttrykk

C ++ er basert på C, så det er alltid et alternativ å løse problemet “av C ++” og “av C”. Når du for eksempel vil sende ut noe til systemkonsollen, kan du gjøre det på "C ++ måte" ved hjelp av cout-utføringsoperatøren, mens "C-måte" du vil bruke en global funksjon som printf:

Synes du ofte det er vanskelig å velge mellom for og med? Bruk for loop når du vet antall repetisjoner, og while loop når antall repetisjoner er ukjent:

Når du bruker kontrolloperatører som hvis / ellers, for, mens, bruk alltid <> og den tilhørende innrykk, selv om kroppen til hele kontrollerklæringen bare består av en linje:

Forsøk å unngå å bruke pauser eller fortsette uttrykk. Bruk dem bare hvis absolutt nødvendig.

C ++ har en exit-funksjon som avslutter programmet umiddelbart. Det er sterkt frarådet å bruke denne funksjonen. Et program bør alltid slutte naturlig ved å komme tilbake til hoveduttalelsen.

Ved å bruke if / else-uttrykk, velg mellom ulike if og ellers mønstre passende, avhengig av forhold som er relatert til hverandre. Unngå unødvendig hvis tester:

Hvis du har en if / else-uttalelse som returnerer en boolsk, kan du returnere testresultatene direkte:

Sjekk aldri boolske verdier med == eller! = Med sant eller usant:

ekstremitet

Hvis du bruker den samme koden to ganger eller mer, kan du finne en måte å fjerne overflødig kode slik at den ikke gjentas. For eksempel kan den plasseres i en hjelpefunksjon. Hvis den gjentatte koden er lik, men ikke helt, kan du prøve å lage en hjelperfunksjon som tar parametere og representerer den forskjellige delen:

Flytt den generiske koden fra if / else-setningen slik at den ikke gjentar seg:

kommentarer

Tittelkommentar. Legg ut en overskriftkommentar som beskriver formålet med filen øverst i hver fil. Anta at leseren av kommentaren din er en avansert programmerer, men ikke noen som allerede har sett koden din før.

Funksjon / konstruksjonshode. Legg inn en overskriftkommentar på hver konstruktør og funksjon i filen din. Overskriften skal beskrive atferden og / eller formålet med funksjonen.

Parametre / Retur. Hvis funksjonen din godtar parametere, kan du kort beskrive deres formål og betydning. Hvis funksjonen din returnerer en verdi, beskriv kort hva den returnerer.

unntakene. Hvis funksjonen din med vilje kaster unntak for visse feiltilfeller, må dette nevnes.

Kommentarer til en linje. Hvis det er et kodeseksjon inne i funksjonen som er lang, sammensatt eller uforståelig, beskriv kort formålet.

TODO. Du bør slette alle // TODO-kommentarer før du avslutter og sender inn programmet.

Funksjoner og prosedyredesign

En godt designet funksjon har følgende egenskaper:

  • Fullfører en tydelig definert oppgave,
  • Tar ikke for mye arbeid
  • Ikke relatert til andre funksjoner uten mål,
  • Lagrer data så komprimert som mulig,
  • Hjelper med å gjenkjenne og dele strukturen i programmet,
  • Hjelper med å bli kvitt overskudd som ellers ville vært til stede i programmet.

Bruk parametere til å sende informasjon fra en funksjon eller når en funksjon trenger å returnere flere verdier. Ikke bruk parametere unødvendig. Merk at a, b og c ikke er parametere i funksjonen nedenfor, siden dette ikke er nødvendig:

Når du vil returnere en verdi fra en funksjon, bruk returverdien:

Når du sender et objekt til en funksjon som en parameter, må du passere det ved referanse, fordi hvis det sendes som en verdi, vil hele objektet kopieres. Det er dyrt å kopiere objekter.

Bruk referansevariabler, ikke pekere. En årsak er at referansevariabler, i motsetning til pekere, ikke kan være NULL:

Hvis du gir et objekt til en funksjon og koden ikke endrer utseendet til objektet, kan du sende det som en konst referanse:

Unngå kjedesamtaler når flere funksjoner ringer hverandre i en kjede uten å returnere en verdi til hovednettet. Sørg for at hoveddelen er en kort beskrivelse av hele programmet:

Klassedesign

innkapsling. Skill objektene dine ved å gjøre alle datafelter i klassen private:

.h vs. cpp. Plasser alltid klasse- og delangivelser i dine egne filer, ClassName.h. Kollaps alltid .h-klassedeklarasjonsfilene inn i #ifndef / define / endif preprocessor-blokkering for å unngå flere deklarasjoner fra samme klasse:

klasse vs struktur. Bruk alltid klassen bare hvis du ikke oppretter en veldig liten og enkel form for data som bare trenger noen få offentlige variabler og eventuelt en konstruktør for å initialisere dem.

Unngå unødvendige felt. Bruk felt til å lagre viktige data om objektene dine, men ikke midlertidige verdier som blir brukt en gang.

Hvordan Yandex bruker dine data og maskinlæring for å tilpasse tjenester - les og se YaC 2019.

Pin
Send
Share
Send
Send