Kommentarer

Svar

En god koder er som en god poolafspiller.

Når du ser en professionel poolspiller, er du måske først imponeret: “Sikker på, de fik alle kuglerne ind, men de havde kun lette skud!” Dette skyldes, at når en poolspiller gør sit skud, tænker hun ikke på, hvilken kugle der går i hvilken lomme, hun tænker også på hvor køkuglen vil ende . Opsætning til det næste skud kræver enorm dygtighed og øvelse, men det betyder også, at det ser let ud.

Nu, når du bringer denne metafor til kode, en god koder skriver kode, der ser ud til at det var let og ligetil at gøre . Mange af eksemplerne fra Brian Kernighan i hans bøger følger dette mønster. En del af “tricket” kommer med en korrekt konceptualisering af problemet og dets løsning . Når vi ikke forstår et problem godt nok, er vi mere tilbøjelige til at komplicere vores løsninger for meget, og vi kan ikke se forenende ideer.

Med en ordentlig konceptualisering af problemet får du alt andet: læsbarhed, vedligeholdelsesevne, effektivitet og korrekthed. Fordi løsningen virker så ligetil, vil der sandsynligvis være færre kommentarer, fordi ekstra forklaring er unødvendig. En god koder kan også se produktets langsigtede vision og forme deres konceptualiseringer i overensstemmelse hermed.

Kommentarer

  • " en god koder skriver kode, der ser ud som om det var let og ligetil at gøre. " < < PRÆCIS! Jeg tror, det er, fordi folk normalt synes, at en god kodeer er en, der kan skrive meget " kloge " hacks. Hvis koden er ren og ikke alt for " smart ", skal det være let, ikke?
  • Min 2 cent: når du ' har fået et sprog med NEM automatiske refaktorer – Java og C # er de to eksempler, jeg kender bedst – det ' det er let at flytte til god kode iterativt. Ellers er du i første omgang nødt til at konceptualisere godt, men der er en slags kylling-ægproblem der.
  • Nogle algoritmer er iboende komplekse. En god koder skal ikke have noget problem med at skrive dem, når de virkelig er nødvendige – og holde dem så læsbare som muligt.
  • @hasenj: ja, det er på grund af dette lemma: dumme mennesker skriver kode, som compileren forstår. Kloge mennesker skriver kode, som dumme mennesker forstår.

Svar

WTF

s pr. minut

( original )

REDIGER: Grundtanken er, at “kodekvalitet” ikke kan sættes i regler, på samme måde som at du ikke kan sætte “god kunst” eller “god poesi” i regler, så du kan lade en computer bestemme sig “ja, god kunst “eller” Nej, dårlig poesi “. I øjeblikket er den eneste måde at se, hvor let forståelig koden er for andre mennesker.

Kommentarer

  • Vi har dette fast på vores tavle på arbejdspladsen: -)
  • @Cape Cod Gunny Var i en onkel Bob ' s bog også
  • Bortset fra at være en stor tegneserie synes jeg det virkelig kommer til det punkt – god kode er kode, som andre mennesker synes er behagelige at læse og vedligeholde.
  • Så sandt, god kode er enhver kode, der ikke er dårlig. F.eks. Er det svært at definere god kode, det er lettere at definere dårlig kode.
  • Normalt finder jeg dem " WTF? " ' s i det gode kodemøde følges kort op af " Oooooh Okay … Jeg kan se, hvad du gjorde der."

Svar

Der er virkelig ingen andre gode kriterier end hvor hurtigt du kan forstå koden. Du får din kode til at se godt ud ved at finde det perfekte kompromis mellem kortfattethed og læsbarhed.

“WTFerne pr. Minut” (ovenfor) er sandt, men det er bare et resultat af den mere generelle regel. Jo flere WTFer jo langsommere forståelse.

Kommentarer

  • @rmx: definer " gør jobbet godt "
  • Nå, at RemoveCustomer -metoden faktisk fjerner cutomeren uden at skrue op. Du kan bruge timer på at få det til at se smukt ud, men det betyder ikke, at det rent faktisk fungerer. ' Hvor hurtigt du kan forstå kode ' er ikke det eneste kriterium for ' god kode ' er det, jeg ' siger.
  • @rmx: men at være fejlfri er underforstået, er ikke ' t det? Hvis din kode ikke ' ikke udfører jobbet korrekt, er det ' ikke kode (endnu).
  • @ rmx: faktisk nej. Hvis din kode er let at forstå, så er det ' let at forstå, hvis det gør det ' dårligt. OTOH, hvis det ' er svært at forstå, er det ' svært at forstå, hvis det gør det ' job overhovedet.
  • @rmx: PS enkelt sagt, din dekrementering () er en klassisk WTF, og det bremser derfor forståelsen af dele af kode, hvor denne funktion bruges

Svar

Du ved, at du skriver god kode, når …

  1. Kunden er glad
  2. Medarbejderne låner din kode som udgangspunkt
  3. Den helt nye fyr / gal fik netop besked på at foretage ændringer i et system, du byggede for 6 måneder siden, og han / hun stillede dig ikke engang et spørgsmål
  4. Din chef beder dig om at udvikle nye widgets til teamet skal bruge
  5. Du ser på koden du skriver i dag og siger til dig selv “Jeg ville ønske jeg havde skrevet kode som denne for to år siden”

Hvordan gør du måle om koden er god …

  • Hvad er svartiden?
  • Hvor mange returrejser til serveren laver den?
  • Vil du personligt bruge applikationen, eller synes du, det er klodset?
  • Vil du bygge det på samme måde næste gang?

God kode fungerer, når den er skulle. God kode kan let ændres, når det er nødvendigt. God kode kan genbruges for at tjene penge.

Kommentarer

  • " Kunden er tilfreds " er retvinklet i forhold til dette.
  • @TRA – Hvis kunden er tilfreds, betyder det, at du forstod kravene og leverede en løsning, de forventede.
  • sikker, men dårlig kode kan gøre det samme.

Svar

En kode, der er

  1. bugfri

  2. genanvendelig

  3. uafhængig

  4. mindre kompleks

  5. veldokumenteret

  6. let at chage

kaldes god kode.

Et godt program fungerer fejlfrit og har ingen fejl. Men hvilke indre kvaliteter frembringer en sådan perfektion ?. Det er ikke noget mysterium, vi har bare brug for nogle lejlighedsvis påmindelser. Uanset om du koder i C / C ++, C #, Java, Basic, Perl, COBOL eller ASM, udviser al god programmering de samme tidskendte kvaliteter: enkelhed, læsbarhed, modulære , lagdeling, design, effektivitet, elegance og klarhedseffektivitet, elegance og klarhed

Kilde: MSDN

Kommentarer

  • Enkelhed, læsbarhed, elegance og klarhed er alle de samme ting. Modularitet og lagdeling er bare metoder til at gøre din kode klar og elegant. Det eneste, der er tilbage på listen, er da effektivitet, som er underforstået, og derudover handler det ofte om at gå på kompromis mellem effektivitet og klarhed.
  • Kontroller dette: goo.gl/hdQt8
  • Koden kan være fejlfri?
  • Nej den kan ' t. (praktisk taget)
  • Effektiv skal føjes til din liste. Hastighed er ikke ' t nødvendigt en primær indikator for god kode, men god kode bør ikke ' t være unødigt langsom eller spild.

Svar

Virker det velkendt?

Philips gav mig muligheden for at se designet på et nyt produkt. Da det udviklede sig, blev jeg mere og mere urolig og begyndte at betro mine bekymringer til min vejleder. Jeg fortalte ham gentagne gange, at designene ikke var “rene”, og at de skulle være “smukke” på den måde, at Dijkstras designs var smukke. Han fandt ikke, at dette var en nyttig kommentar.Han mindede mig om, at vi var ingeniører, ikke kunstnere. I hans sind udtrykte jeg simpelthen min smag, og han ønskede at vide, hvilket kriterium jeg brugte til at dømme. Jeg kunne ikke fortælle ham det! Fordi jeg ikke kunne forklare, hvilke principper der blev overtrådt, blev mine kommentarer simpelthen ignoreret, og arbejdet fortsatte. Da jeg mærkede, at der måtte være en måde at forklare og give motivation til min “smag”, begyndte jeg at prøve at finde et princip, der skelner mellem gode designs og dårlige. Ingeniører er meget pragmatiske; de beundrer måske skønhed, men de søger hjælp. Jeg forsøgte at finde en forklaring på, hvorfor “skønhed” var nyttigt.

Se resten her .

Kommentarer

  • Da linket i @mlvljr ' s indlæg er brudt , her er et link til siden Google Bøger: books.google.co.in/…
  • @balajeerc Tak (jeg fik også linket, så det peger på en Springer-hostet version af den samme pdf) 🙂

Svar

bortset fra naturlige kodekvalitets kriterier (minimum kopi / indsæt, ingen spaghetti osv.) skal en god industriel kode altid se lidt naiv ud, lidt for ordentlig, ligesom 

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

i modsætning til 

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

Kommentarer

  • Men betyder do_not_create = false “videregive false som do_not_create argumentet, så det vil blive oprettet ”eller“ pas s false som do_create argumentet, så det ikke oprettes ”? På et sprog, hvor du kan bruge argumentnavne, foretrækker jeg cache.get (key:i, create: false); i += 1;.

Svar

Måske vil et svar ved at illustrere det modsatte hjælpe (plus det er en undskyldning for at få XKCD herinde).

alt-tekst

God kode er

  • let at forstå,
  • let at vedligeholde ,
  • forsøger ikke at løse alle problemer, kun den ene ved hånden
  • lever i lang tid uden at få udviklere til at se efter alternativer

Eksempler inkluderer

  • Apache Commons
  • Forårsramme
  • Dvale ramme

Svar

Jeg vil bare gå med “vedligeholdelig”

Al kode skal opretholdes: intet behov for at gøre opgaven vanskeligere end nødvendigt

Hvis nogen læser ikke forstår dette enkle krav eller har brug for at blive stavet, skal denne læser ikke skrive kode …

Svar

God kode vil være forskellig for hver person, og det sprog, de arbejder med, har også indflydelse på, hvad der kan overvejes at være god kode. Generelt når jeg nærmer mig et projekt, ser jeg efter følgende ting:

  • Hvordan er projektet organiseret? Er kildefiler organiseret på en ren måde, og kan jeg finde kode uden for meget indsats?
  • Hvordan er koden organiseret? Er er tydeligt dokumenteret, hvad koden i filen gør, såsom ved brug af en filoverskrift, eller ved brug af hver klasse, der er i sin egen fil? Er der funktion i filen, der ikke længere bruges i applikationen?
  • Hvordan er funktionerne organiseret? Er der et klart mønster, hvor variabler erklæres, eller er det et ret tilfældigt mønster? Har koden en logisk strøm til den og undgår unødvendige kontrolstrukturer? Er alt tydeligt dokumenteret med kode, der er selvdokumenterende, hvor det er nødvendigt, og kommentarer udtrykker klart, hvorfor og / eller hvordan, hvad koden laver?

Ud over alt dette, gør designet af anvendelse giver mening som helhed? Koden, der findes i applikationen, kan være den bedste i verden, men det kan stadig være en smerte at arbejde med, hvis det overordnede design af applikationen ikke giver mening.

Svar

Lad mig være uenig i læsbarheden. Nej, ikke helt: God kode skal kunne læses, og det kan let opnås med nok kommentarer.

Men jeg betragter to slags WTF: dem, hvor du spekulerer på, om programmøren kom længere end programmering 101, og dem, hvor du absolut ikke forstår kodens genialitet. Nogle koder kan se meget underlige ud først, men er faktisk en meget opfindsomme løsning på et hårdt problem. Den anden bør ikke tælle i WTF-måleren og kan undgås ved kommentarer.

Meget læsbar kode kan være meget, meget langsom . En mindre læselig løsning kan give mange gange forbedring i hastighed. R er et godt eksempel på et sprog, hvor det ofte er sandt. Man kan lide at undgå for-løkker der så meget som muligt.Generelt vil jeg betragte den hurtigste kode som den bedre kode, selvom den er mindre læsbar. Det vil sige, hvis forbedringen er væsentlig, selvfølgelig, og der indsættes nok kommentarer til at forklare, hvad koden gør.

Endnu mere kan hukommelsesadministration være afgørende i mange videnskabelige applikationer. Kode, der er meget læselig, har tendens til at være lidt sjusket i hukommelsesforbruget: der er bare flere objekter oprettet. I nogle tilfælde gør smart brug af hukommelse koden igen mindre læselig. Men hvis du f.eks. Jonglerer rundt med gigabyte DNA-sekvenser, er hukommelse en afgørende faktor. Igen betragter jeg, at mindre hukommelsesintensiv kode er bedre kode uanset læsbarhed.

Så ja, læsbarhed er vigtig for god kode. Jeg kender Uwe Liggis adagium: At tænke ondt og computere er billige. Men inden for mit felt (statistisk genomik) betragtes beregningstider på en uge og hukommelsesforbrug på over 40 Gb ikke som unormale. Så en forbedring på dobbelt så hurtig som halvdelen af hukommelsen er meget mere værd end den ekstra læsbarhed.

Kommentarer

  • Ingen regel / regler uden undtagelse
  • Lad mig være uenig i din uenighed: du siger, at hastighed i dit felt er meget vigtig og siger, at det er vigtigere end læsbarhed. Jeg er uenig, du skal stræbe efter at bruge den rette balance. Hvis der ikke er behov for hastighed, for eksempel til et interface på højt niveau, foretrækker du måske noget, der er let at vedligeholde, hvis der er brug for hastighed, er jeg enig med dig. I stedet for hårde regler er det bedre at bruge sund fornuft, og du bør alligevel undgå for tidlig optimering.
  • @BlueTrin Hvorfor ikke begge hjerne-kompilere disse hi-perf kildekoder, og også dokumentere helvede af hvad ' der foregår der (lige der i kommentarer)?

Svar

Så vidt det går for mig … Jeg ved, at jeg skriver god kode, når en kollega, der arbejder på et andet projekt, kommer og er i stand til at springe ind og forstå, hvad jeg laver, uden at jeg går over hver blok af kode og viser, hvad den laver.
I stedet for at han sagde: “Vent et øjeblik, hvad ?!” Han siger, “Åh, ok, jeg kan se, hvad du gjorde der.”

God kode har heller ikke en masse luskede løsninger eller “hacks”. Linjer når du, mens du skriver det, også siger til dig selv: “Jeg ved, dette er ikke en god måde at gøre det på, men jeg bliver bare nødt til at gøre det på denne måde for nu. Jeg vil minde mig om at forbedre det senere … “

Svar

Der er mange funktioner i” god “kode , men det vigtigste, IMHO, er læsbarhed og vedligeholdelsesevne.

Din kode vil indeholde bugs, vil sandsynligvis blive udvidet og genbrugt, og burde genovervejes på et eller andet tidspunkt – selvom det er, du besøger det igen, er chancerne for, at du ikke vil have en anelse om, hvad fanden du gjorde i første omgang, at gøre dig selv en tjeneste og læg ikke nogen barrierer i vejen.

Sikker på, brug den komplekse endnu uber-effektive algoritme, men sørg for at bruge lidt ekstra tid på at dokumentere det, men ellers gør din kode klar og konsekvent.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *