Hva betyr det å skrive “ god kode ”? [lukket]

Det er egentlig ingen andre gode kriterier enn hvor fort du kan forstå koden. Du får koden din til å se bra ut ved å finne det perfekte kompromisset mellom kortfattethet og lesbarhet.

«WTF» s per minutt «(over) er sant, men det er bare en følge av den mer generelle regelen. Jo flere WTF-er jo langsommere forståelse.

Kommentarer

• @rmx: definer " gjør jobben vel "
• Vel, at RemoveCustomer -metoden faktisk fjerner kutteren uten å skru opp. Du kan bruke timer på å få det til å se pent ut, men det betyr ikke at det faktisk fungerer. ' Hvor fort du kan forstå kode ' er ikke det eneste kriteriet for ' god kode ' er det jeg ' sier.
• @rmx: men å være feilfri er underforstått, ikke ' t det? Hvis koden din ikke ' ikke gjør jobben ordentlig, er den ikke ' (ennå).
• @ rmx: faktisk nei. Hvis koden din er lett å forstå, er det ' lett å forstå hvis det gjør det ' sin jobb dårlig. OTOH, hvis det ' er vanskelig å forstå, er det ' vanskelig å forstå hvis det gjør det ' jobb i det hele tatt.
• @rmx: PS enkelt sagt, din reduksjon () er en klassisk WTF og dermed bremser forståelsen av deler av koden der denne funksjonen brukes

En kode som er

1. feilfri

2. gjenbrukbar

3. uavhengig

4. mindre kompleks

5. godt dokumentert

6. lett å chage

kalles god kode.

Et godt program fungerer feilfritt og har ingen feil. Men hvilke indre kvaliteter gir en slik perfeksjon ?. Det er ikke noe mysterium, vi trenger bare en og annen påminnelse. Enten du koder i C / C ++, C #, Java, Basic, Perl, COBOL eller ASM, har all god programmering de samme tidskrevne egenskapene: enkelhet, lesbarhet, modularitet , lagdeling, design, effektivitet, eleganse og klarhetseffektivitet, eleganse og klarhet

Kilde: MSDN

Kommentarer

• Enkelhet, lesbarhet, eleganse og klarhet er det samme. Modularitet og lagdeling er bare metoder for å gjøre koden din klar og elegant. Det eneste som er igjen på listen da er effektivitet, som er underforstått, og dessuten handler det ofte om å gå på kompromiss mellom effektivitet og klarhet.
• Sjekk dette: goo.gl/hdQt8
• Koden kan være feilfri?
• Nei den kan ' t. (praktisk talt)
• Effektiv bør legges til listen din. Hastighet er ikke ' t nødvendig er en primær indikator for god kode, men god kode bør ikke ' t være unødvendig treg eller sløsende.

Virker dette kjent?

Philips ga meg muligheten til å se designen til et nytt produkt. Etter hvert som det utviklet seg, ble jeg stadig mer urolig og begynte å betro mine bekymringer til veilederen min. Jeg fortalte ham gjentatte ganger at designene ikke var «rene» og at de skulle være «vakre» slik Dijkstras design var vakre. Han syntes ikke dette var noen nyttig kommentar.Han minnet meg på at vi var ingeniører, ikke kunstnere. I hans sinn uttrykte jeg ganske enkelt min smak, og han ønsket å vite hvilket kriterium jeg brukte for å dømme. Jeg klarte ikke å fortelle ham det! Fordi jeg ikke kunne forklare hvilke prinsipper som ble brutt, ble kommentarene mine rett og slett ignorert og arbeidet fortsatte. Da jeg kjente at det må være en måte å forklare og gi motivasjon for min «smak», begynte jeg å prøve å finne et prinsipp som skiller god design fra dårlig. Ingeniører er veldig pragmatiske; de beundrer kanskje skjønnhet, men de søker nytte. Jeg prøvde å finne en forklaring på hvorfor «skjønnhet» var nyttig.

Se resten her .

Kommentarer

• Siden lenken i @mlvljr ' innlegg er ødelagt , her er en lenke til Google Bøker-siden: books.google.co.in/…
• @balajeerc Takk (jeg fikset også lenken, så den peker på en Springer-vert versjon av samme pdf) 🙂

bortsett fra naturlige kodekvalitetskriterier (minimum kopi / lim, ingen spaghetti osv.), bør en god industriell kode alltid se litt naiv ut, litt for ordentlig, som

int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i; 

i motsetning til

Record r = cache.get(i++, false); 

Kommentarer

• Men betyr do_not_create = false «pass false som do_not_create argumentet slik at det vil bli opprettet ”eller” pas s false som do_create argumentet slik at det ikke blir opprettet ”? På et språk der du kan bruke argumentnavn, foretrekker jeg cache.get (key:i, create: false); i += 1;.

Jeg vil bare gå med «vedlikeholdbar»

All kode må opprettholdes: det er ikke nødvendig å gjøre oppgaven vanskeligere enn nødvendig

Hvis noen lesere ikke forstår dette enkle kravet eller trenger det stavet, bør ikke leseren skrive kode …

God kode kommer til å være forskjellig for hver person, og språket de jobber med har også innvirkning på det som kan vurderes å være god kode. Vanligvis når jeg nærmer meg et prosjekt ser jeg etter følgende ting:

• Hvordan er prosjektet organisert? Er kildefiler organisert på en ren måte, og kan jeg finne kode uten for mye innsats?
• Hvordan er koden organisert? Er det tydelig dokumentert hva koden i filen gjør, for eksempel ved bruk av en filoverskrift, eller ved bruk av hver klasse som ligger i sin egen fil? Er det funksjon i filen som ikke lenger brukes i applikasjonen?
• Hvordan er funksjonene organisert? Er det et tydelig mønster hvor variabler blir deklarert, eller er det et ganske tilfeldig mønster? Har koden en logisk flyt til den og unngår unødvendige kontrollstrukturer? Er alt tydelig dokumentert med at koden er selvdokumenterende hvor det er behov, og kommentarer uttrykker tydelig hvorfor og / eller hvordan det koden gjør?

Utover alt dette, gjør utformingen av applikasjon er fornuftig som en helhet? Koden som ligger i applikasjonen kan være den beste i verden, men det kan fortsatt være vondt å jobbe med hvis den generelle utformingen av applikasjonen ikke gir mening.

La meg være uenig om lesbarheten. Nei, ikke helt: God kode skal kunne leses, og det kan enkelt oppnås med nok kommentarer.

Men jeg vurderer to typer WTF: de der du lurer på om programmereren kom lenger enn programmering 101, og de der du absolutt ikke fatter kodenes genialitet. Noen koder kan se veldig rart ut på først, men er faktisk en veldig oppfinnsom løsning på et vanskelig problem. Den andre skal ikke telle i WTF-måleren, og kan unngås av kommentarer.

Svært lesbar kode kan være veldig, veldig treg . En mindre lesbar løsning kan gi mange ganger bedre hastighet. R er et godt eksempel på et språk der det ofte stemmer. Man liker å unngå forløkker der så mye som mulig.Generelt sett vil jeg anse at den raskeste koden er den bedre koden selv om den er mindre lesbar. Det vil si at hvis forbedringen er betydelig selvfølgelig, og det settes inn nok kommentarer for å forklare hva koden gjør.

Enda mer kan minneadministrasjon være avgjørende i mange vitenskapelige applikasjoner. Kode som er veldig leselig, pleier å være litt slurvete i minnebruk: det er bare flere objekter opprettet. I noen tilfeller gjør smart bruk av minne koden igjen mindre lesbar. Men hvis du sjonglerer rundt gigabyte DNA-sekvenser for eksempel, er hukommelse en avgjørende faktor. Igjen anser jeg at mindre minneintensiv kode er bedre kode, uavhengig av lesbarhet.

Så ja, lesbarhet er viktig for god kode. Jeg kjenner adagiet til Uwe Liggis: Å tenke vondt og datamaskiner er billige. Men i mitt felt (statistisk genomikk) regnes ikke beregningstider på en uke og minnebruk på over 40 Gb som unormale. Så en forbedring av dobbelt så høy hastighet og halve minnet er verdt mye mer enn den ekstra lesbarheten.

Kommentarer

• Ingen regel / regler uten unntak
• La meg være uenig i uenigheten din: du sier at i ditt felt er hastighet veldig viktig og sier at det er viktigere enn lesbarhet. Jeg er uenig, du bør prøve å bruke riktig balanse. Hvis hastighet ikke er nødvendig, for eksempel for et grensesnitt på høyt nivå, foretrekker du kanskje noe som er lett å vedlikeholde. Hvis hastighet er nødvendig, er jeg enig med deg. I stedet for harde regler er det bedre å bruke sunn fornuft, og du bør unngå for tidlig optimalisering uansett.
• @BlueTrin Hvorfor ikke både hjernekompilere de hi-perf kildekodene, og også dokumentere helvete av hva ' skjer der (akkurat der i kommentarer)?

Så langt det går for meg … Jeg vet at jeg skriver god kode når en kollega som jobber med et annet prosjekt kommer sammen og er i stand til å hoppe inn og forstå hva jeg gjør uten at jeg går over hver blokk med kode og viser hva den gjør.
I stedet for at han sa: «Vent litt, hva ?!» Han sier: «Å, ok, jeg skjønner hva du gjorde der.»

God kode har heller ikke mange snike løsninger eller «hacks». Linjer når, mens du skriver det, du også sier til deg selv: «Jeg vet at dette ikke er en god måte å gjøre det på, men jeg må bare gjøre det på denne måten for nå. Jeg vil minne meg selv om å forbedre det senere … «

Det er mange funksjoner med» god «kode , men det viktigste, IMHO, er lesbarhet og vedlikeholdsevne.

Koden din vil inneholde feil, vil sannsynligvis utvides og brukes på nytt, og burde omformuleres på et tidspunkt – selv om det er du som besøker det på nytt, er sjansen stor for at du ikke vil ha en anelse om hva i helvete du gjorde i utgangspunktet selv en tjeneste og ikke legg noen barrierer i veien.

Visst, bruk den kompliserte, men uber-effektive algoritmen, men sørg for at du bruker litt ekstra tid på å dokumentere den, men ellers gjør din koden er tydelig og konsekvent.