Vad betyder det att skriva “ bra kod ”? [stängd]

Det finns egentligen inga bra kriterier annat än hur snabbt du kan förstå koden. Du får din kod att se bra ut genom att hitta den perfekta kompromissen mellan kortfattning och läsbarhet.

”WTF” per minut ”(ovan) är sant men det är bara en följd av den mer allmänna regeln. Ju fler WTFs desto långsammare blir förståelsen.

Kommentarer

• @rmx: definiera " gör jobbet väl "
• Tja, att metoden RemoveCustomer faktiskt tar bort cutomeren utan att skruva upp den. Du kan spendera timmar på att få det att se snyggt ut, men det betyder inte att det faktiskt fungerar. ' Hur snabbt du kan förstå koden ' är inte det enda kriteriet för ' bra kod ' är vad jag ' säger.
• @rmx: men att vara felfri är underförstådd, är inte ' t det? Om din kod inte ' inte gör jobbet ordentligt är det ' inte kod (ännu).
• @ rmx: faktiskt nej. Om din kod är lätt att förstå är det ' lätt att förstå om det gör det ' jobb dåligt. OTOH, om det ' är svårt att förstå, är det ' svårt att förstå om det gör det ' jobb alls.
• @rmx: PS Enkelt uttryckt är din minskning () en klassisk WTF och därmed saktar förståelsen av delar av koden där den här funktionen används

En kod som är

1. buggfri

2. återanvändbar

3. oberoende

4. mindre komplex

5. väldokumenterad

6. lätt att chage

kallas bra kod.

Ett bra program fungerar felfritt och har inga fel. Men vilka interna egenskaper ger en sådan perfektion ?. Det är inget mysterium, vi behöver bara enstaka påminnelser. Oavsett om du kodar i C / C ++, C #, Java, Basic, Perl, COBOL eller ASM, har alla bra programmering samma kvalitetsegenskaper: enkelhet, läsbarhet, modularitet , skiktning, design, effektivitet, elegans och klarhetseffektivitet, elegans och tydlighet

Källa: MSDN

Kommentarer

• Enkelhet, läsbarhet, elegans och tydlighet är alla samma sak. Modularitet och lager är bara metoder för att göra din kod tydlig och elegant. Det enda som finns kvar i listan är då effektivitet, vilket är underförstått, och dessutom handlar det ofta om att kompromissa mellan effektivitet och tydlighet.
• Kontrollera detta: goo.gl/hdQt8
• Koden kan vara felfri?
• Nej den kan ' t. (praktiskt taget)
• Effektiv bör läggas till i din lista. Hastighet är inte ' t nödvändig en primär indikator för bra kod, men bra kod borde inte ' t vara onödigt långsam eller slösaktig.

Verkar detta bekant?

Philips gav mig möjlighet att titta på designen av en ny produkt. När det utvecklades blev jag alltmer orolig och började betona mina bekymmer till min handledare. Jag sa upprepade gånger till honom att designen inte var ”rena” och att de skulle vara ”vackra” på det sätt som Dijkstras mönster var vackra. Han tyckte inte att detta var en användbar kommentar.Han påminde mig om att vi var ingenjörer, inte konstnärer. I hans sinne uttryckte jag helt enkelt min smak och han ville veta vilket kriterium jag använde för att göra mitt omdöme. Jag kunde inte berätta för honom! Eftersom jag inte kunde förklara vilka principer som överträddes ignorerades mina kommentarer helt enkelt och arbetet fortsatte. När jag kände att det måste finnas ett sätt att förklara och ge motivation för min ”smak” började jag försöka hitta en princip som skiljer bra design från dåliga. Ingenjörer är mycket pragmatiska; de kanske beundrar skönhet, men de söker nytta. Jag försökte hitta en förklaring till varför ”skönhet” var användbart.

Se resten här .

Kommentarer

• Eftersom länken i @mlvljr ' s inlägg är trasig , här är en länk till Google Books-sidan: books.google.co.in/…
• @balajeerc Tack (jag fixade också länken, så den pekar på en Springer-värdversion av samma pdf) 🙂

bortsett från naturliga kodkvalitetskriterier (minsta kopia / klistra in, ingen spagetti, etc.) en bra industriell kod bör alltid se lite naiv ut, lite för ordalig, som

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

i motsats till

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

Kommentarer

• Men betyder do_not_create = false ”passera false som do_not_create argument så att det kommer att skapas ”eller” pas s false som do_create argument så att det inte skapas ”? På ett språk där du kan använda argumentnamn föredrar jag cache.get (key:i, create: false); i += 1;.

Kanske skulle ett svar genom att illustrera det motsatta hjälpa (plus att det är en ursäkt för att få XKCD här).

Bra kod är

• enkel att förstå,
• lätt att underhålla ,
• försöker inte lösa alla problem bara den som finns till hands
• lever vidare länge utan att utvecklarna letar efter alternativ

Exempel inkluderar

• Apache Commons
• Spring ram
• Viloläge ram

Jag går helt enkelt med ”underhållbar”

All kod måste underhållas: inget behov av att göra den uppgiften svårare än nödvändigt

Om någon läsare inte förstår detta enkla krav eller behöver det stavas, ska den läsaren inte skriva kod …

Bra kod kommer att vara annorlunda för varje person och språket de jobbar med har också en inverkan på vad som kan övervägas att vara bra kod. När jag närmar mig ett projekt letar jag i allmänhet efter följande saker:

• Hur är projektet organiserat? Är källfilerna ordnade på ett rent sätt och kan jag hitta kod utan alltför mycket ansträngning?
• Hur är koden organiserad? Är är tydligt dokumenterat vad koden i filen gör, till exempel genom användning av en filrubrik, eller genom användning av varje klass som finns i sin egen fil? Finns det funktioner i filen som inte längre används i applikationen?
• Hur är funktionerna organiserade? Finns det ett tydligt mönster där variabler deklareras, eller är det ett ganska slumpmässigt mönster? Har koden ett logiskt flöde och undviker onödiga kontrollstrukturer? Är allt tydligt dokumenterat med att koden är självdokumenterande där det behövs och kommentarer tydligt uttrycker varför och / eller hur koden gör?

Utöver allt detta gör designen av applikation meningsfullt som helhet? Koden som finns i applikationen kan vara den bästa i världen, men det kan fortfarande vara svårt att arbeta med om den övergripande utformningen av applikationen inte ger någon mening.

Låt mig vara oense om läsbarheten. Nej, inte helt: Bra kod ska vara läsbar och det kan enkelt uppnås med tillräckligt med kommentarer.

Men jag tänker på två typer av WTF: de där du undrar om programmeraren kom längre än programmering 101, och de där du absolut inte förstår kodens genialitet. Vissa koder kan se väldigt konstiga ut först, men är faktiskt en mycket uppfinningsrik lösning på ett svårt problem. Den andra borde inte räknas i WTF-mätaren och kan undvikas av kommentarer.

Mycket läsbar kod kan vara väldigt, mycket långsam . En mindre läsbar lösning kan ge en mångfaldig förbättring av hastigheten. R är ett bra exempel på ett språk där det ofta är sant. Man gillar att undvika for-loopar där så mycket som möjligt.I allmänhet anser jag att den snabbaste koden är den bättre koden även om den är mindre läsbar. Det vill säga om förbättringen är väsentlig av kurs och tillräckligt med kommentarer läggs in för att förklara vad koden gör.

Ännu mer kan minneshantering vara avgörande i många vetenskapliga tillämpningar. Kod som är mycket läsbar, tenderar att vara lite slarvig i minnesanvändningen: det skapas bara fler objekt. I ganska många fall gör smart användning av minnet koden igen mindre läsbar. Men om du jonglerar runt till exempel gigabyte DNA-sekvenser är minne en avgörande faktor. Återigen anser jag att ju mindre minneintensiv kod desto bättre kod, oavsett läsbarhet.

Så ja, läsbarhet är viktigt för bra kod. Jag känner till Uwe Liggis adagium: Att tänka ont och datorer är billiga. Men inom mitt område (statistisk genomik) anses beräkningstider på en vecka och minnesanvändning på över 40 Gb inte vara onormala. Så en förbättring med dubbelt så hög hastighet och halva minnet är värt mycket mer än den extra läsbarheten.

Kommentarer

• Ingen regel / regler utan undantag
• Låt mig inte hålla med din oenighet: du säger att hastighet i ditt fält är mycket viktigt och säger att det är viktigare än läsbarhet. Jag håller inte med, du bör sträva efter att använda rätt balans. Om hastighet inte behövs, till exempel för ett gränssnitt på hög nivå, kanske du föredrar något lätt att underhålla, om hastighet behövs så håller jag med dig. I stället för hårda regler är det bättre att använda sunt förnuft och du bör undvika för tidig optimering ändå.
• @BlueTrin Varför inte både hjärnkompilera de högpresterande källkoderna och också dokumentera helvetet av vad ' pågår där (precis där i kommentarer)?

Så långt det går för mig … Jag vet att jag skriver bra kod när en kollega som jobbar med ett annat projekt kommer och kan hoppa in och förstå vad jag gör utan att jag går över varje block av kod och visar vad den gör.
Istället för att han sa: ”Vänta lite, vad ?!” Han säger ”Åh, okej, jag förstår vad du gjorde där.”

Bra kod har inte heller en hel del snygga lösningar eller ”hack”. Linjer när, medan du skriver det, du också säger till dig själv, ”Jag vet att detta inte är ett bra sätt att göra det, men jag måste bara göra det så här för nu. Jag kommer påminna mig om att förbättra det senare … ”

Det finns många funktioner med” bra ”kod , men det viktigaste, IMHO, är läsbarhet och underhållbarhet.

Din kod kommer att innehålla buggar, kommer troligen att utvidgas och återanvändas, och borde tänkas om någon gång – även om det är du som besöker det igen, är chansen att du inte kommer att ha en aning om vad du gjorde i första hand, att göra dig själv en tjänst och sätt inte några hinder i vägen.

Visst, använd den komplexa men ändå uber-effektiva algoritmen, men se till att du spenderar lite extra tid på att dokumentera den, men annars gör din kod tydlig och konsekvent.