Sourcecode: Kunsten å skrive god kode

[kilogram]

Kunsten å skrive god kode

Å skrive god kode kan ofte vere svært vanskelig. Alle kan sjå forskjell på programmeringskode skrive av ein erfaren programmerar og ein nybyrjar. I denne artikkelen skal me vise deg korleis du kan få din kjeldekode til å verte meir oversiktlig.

 

Les artikkelen her

[☀ ❄]

Jeg syns det var en fin artikkel, som tok for seg det nybegynnere ofte er minst flinke med -- skrive stilrent. Jeg syns derimot at det er et lite "men", for artikkelforfatteren sier at "sånn er det, det er den eneste (gode) måten, punktum".

 

Konkret eksempel:

I stort sett alle språk er det ikkje noko positivt å benytte seg av underscore (_) i variabel- og metodenamn.

 

Bjarne Stroustrup bruker underscore. The Standard C++ Library bruker underscore ekstensivt. Vil artikkelforfatteren påstå at The Standard C++ Library er et dårlig stykke programmeringskunst?

 

Personlig mener jeg -- og det er det generelt enighet om, har jeg inntrykk av -- at det ikke er så farlig hva slags stil man benytter seg av, så lenge man har en stil, og så lenge man er konsekvent.

[kilogram]

Konkret eksempel:

I stort sett alle språk er det ikkje noko positivt å benytte seg av underscore (_) i variabel- og metodenamn.

 

Bjarne Stroustrup bruker underscore. The Standard C++ Library bruker underscore ekstensivt. Vil artikkelforfatteren påstå at The Standard C++ Library er et dårlig stykke programmeringskunst?

 

Det er ikkje det det står, men eg kan skjønne at det vert oppfatta slik. Eg har difor endra ordlyden litt i artikkelen.

 

Normalt så reduserer bruken av underscores leseligheten til koden. Dette er derimot ikkje tilfellet når det gjeld C++-kode, der det er ein vanleg kodestandard, og det passar betre inn med dei syntaktiske elementa i koden. Derimot passar underscore svært dårlig inn i t.d. Basic- og Pascal-baserte språk, og i svært mange andre språk.

 

Personlig mener jeg -- og det er det generelt enighet om, har jeg inntrykk av -- at det ikke er så farlig hva slags stil man benytter seg av, så lenge man har en stil, og så lenge man er konsekvent.

 

Dette er eit godt poeng, som eg kan vere einig i at kanskje kom for dårleg fram i artikkelen.

[Format71]

Jeg må si jeg var litt skuffet over artikkelen. Ut fra overskriften trodde jeg at man skulle se på måter å skrive 'god' kode, ikke 'fin' kode...

 

Men for all del. Det gjør ikke noe om koden er lesbar. Det gjør ting mye enklere både for en selv og andre.

 

-Vegar

[j000rn]

Et par kommentarer...

 

 

*** IKKE bruk norske variabelnavn og kommentarer!!!

Jeg for min del har aldri jobbet i et firma hvor alle ansatte er norskspråklige. Dette har gjeldt både små og mellomstore firmaer. I tillegg hender det både titt og ofte at andre skal se på koden, og hvem vet hva som skjer med firmaet/produktet du jobber med i fremtiden?

 

 

*** Vær konsistent!

Result, result, Navn, navn <--- Bestem deg for én måte å skrive disse på (okay, de var i forskjellige programmeringsspråk, og for alt jeg vet har Sun, PHP og "C" forskjellig "best-practice" her men alikevell...)

 

Jeg synes faktisk det er bedre å lese kode som "er konsistent feil enn som er ukonsistent riktig"... :-P

 

 

*** Antall linjer pr. funksjon

Bør aldri ta opp mer plass enn maks en skjermstørrelse. Funskjoner bør være små og selvforklarende.

 

 

*** {}

Personlig synes jeg å ikke putte { på ny linje ødelegger lesbarheten ganske mye også.

 

 

*** ()

Parantes kan både forbedre og ødelegge lesbarheten.

I eksempelet ditt er det en parantes for mye:

if (Liste.LangtFunksjonsNavnNummerEn(Ting1) and

(Liste.LangtFunksjonsNavnNummerTo(Ting2)) then

Bør være:

if ( Liste.LangtFunksjonsNavnNummerEn(Ting1) and

Liste.LangtFunksjonsNavnNummerTo(Ting2) ) then

 

 

*** Mellomrom

En ting som irriterer meg ganske mye er folk som ikke bruker mellomrom mellom + når de skal f.eks. legge sammen string's:

string Result = "Your name is "+FirstName+" "+SurName+". And age "+Age;

Gjøres utrolig mye mer lesbart når man legger til noen mellomrom:

string Result = "Your name is " + FirstName + " " + SurName + ". And age " + Age;

 

 

 

 

- jørn

[kommers]

*** {}

Personlig synes jeg å ikke putte { på ny linje ødelegger lesbarheten ganske mye også.

Hvorvidt man foretrekker { på ny linje etter deklarering av metodenavn og signatur, er vel kun en smaksak. Jeg vet ikke sikkert om dette er språkavhengige normer som brer om seg i de forskjellige miljøene eller om det kun er den individuelle programmerer som har vokst opp med enten den ene eller andre måten i "morsmelka". (Vet du?) Men så lenge man er konsekvent bør det ikke ha så mye å si vil jeg påstå, men alle foretrekker vel i bunn og grunn helst å se koden akkurat slik man er vant til å se den, nemlig slik man selv formaterer den.

 

PS: Selv liker jeg best { på samme linje som metodedeklarasjonen, dermed "sparer" jeg en nesten helt blank linje, og det blir mindre scrolling når man må bevege seg opp eller ned i koden. Men det er vel fordi jeg kun er vant med det.

[CWalken]

*** {}

Personlig synes jeg å ikke putte { på ny linje ødelegger lesbarheten ganske mye også.

 

Når det gjelder Java ligger deres code convensions på nettet: Code Conventions for the Java Programming Language.

 

When coding Java classes and interfaces, the following formatting rules should be followed:

 

No space between a method name and the parenthesis "(" starting its parameter list

 

Open brace "{" appears at the end of the same line as the declaration statement

 

Closing brace "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement the "}" should appear immediately after the "{"

[TAFT]

Jeg hiver meg på emnet kommentarer/dokumentering og vil understreke at det ikke er god praksis å legge kommentarer på samme linje som koden. Dette reduserer lesbarheten betraktelig.

Videre er det dårlig praksis å kommentere "as you go", dvs på nesten hver linje. Kommentarer innimellom linjene skal være der for å gi utfyllende informasjon hvor det er spesielt nødvendig, ikke for å forklare hva du gjør (da har du skrevet dårlig).

I stedet bør du kommentere blokker av kode (f.eks. foran en while-loop eller en if). Noen ganger er det mer enn nok å kommentere foran metoden/property/funksjon. Man bør også forklare intensjonen med koden, ikke bare hva den gjør. OG - ikke glem entry/exit points.

 

Bruker du .net finnes det jo ypperlige verktøy for å dokumentere.

 

Og: Til de som tror at man ikke trenger å dokumentere/kommentere kode man har skrevet kun for egne øyne - GLEM DET. Etter noen måneder (uker i mitt tilfelle - begynner vel å bli gammel ) har du problemer med å skjønne hva du tenkte på.

 

Og enda en ting (som poengtert av flere): God kode er ikke nødvendigvis det samme som lesbar kode (som artikkelen handler om). God kode er alltid lesbar kode (postulat!). Lesbar kode kan være elendig.

 

Hva som må til for å skrive god kode er langt utenfor denne tråden, men en generell innføring i matematiske algoritmer (å ja da!) er grunnleggende.

Jeg tror aldri jeg ville ansatt en koder som ikke har dette, i hvert fall ikke som annet enn en trainee.

Endret 18. juni 2004 av TAFT

[eirikhm]

God kode er alltid lesbar kode (postulat!).

 

nåja. om du har tatt turen innom ting John Carmack har skrevet (doom / quake 1 / 2) så er det nok ikke alltid tilfelle.

 

IMO så er det å være konsistent det viktigeste. Folk som er relativt ferske liker ofte litt luftoig kode, men etterhvert blir det ingen problem å ha ting litt mer kompant (iallefall i mitt tilfelle).

[TAFT]

nåja. om du har tatt turen innom ting John Carmack har skrevet (doom / quake 1 / 2) så er det nok ikke alltid tilfelle.

 

IMO så er det å være konsistent det viktigeste. Folk som er relativt ferske liker ofte litt luftoig kode, men etterhvert blir det ingen problem å ha ting litt mer kompant (iallefall i mitt tilfelle).

Nåja?

Jeg står fast på mitt. Dersom koden ikke er lesbar, så er den heller ikke god. Den kan være mye annet, bl.a. veldig effektiv (mht ressurser), men god - nei!

[fjotten]

nåja. om du har tatt turen innom ting John Carmack har skrevet (doom / quake 1 / 2) så er det nok ikke alltid tilfelle.

 

IMO så er det å være konsistent det viktigeste. Folk som er relativt ferske liker ofte litt luftoig kode, men etterhvert blir det ingen problem å ha ting litt mer kompant (iallefall i mitt tilfelle).

Nåja?

Jeg står fast på mitt. Dersom koden ikke er lesbar, så er den heller ikke god. Den kan være mye annet, bl.a. veldig effektiv (mht ressurser), men god - nei!

Nå kommer vi inn på en sånn filosofisk debatt om betydningen av ord. Skal en kode være god mener jeg den bør smake godt, ergo, jeg har aldri sett god kode.

[Zethyr]

joda, prøv å print ut kilden til DukeNukem3D, og ta litt sukker & syltetøy på den. Da har du _god_ kode.

Neida, eneste som trengs for god kode er at den må være strukturert og selvforklarende.

[fjotten]

Hehe, skal prøve det

 

Neida, skjønner selvsagt hva som menes med at god kode bør ha god kommentar og være selvforklarende, for å bruke dine ord Zethyr.

[TAFT]

Kode blir enda bedre med en pils til

[Bøb]

*** {}

Personlig synes jeg å ikke putte { på ny linje ødelegger lesbarheten ganske mye også.

 

Når det gjelder Java ligger deres code convensions på nettet: Code Conventions for the Java Programming Language.

 

When coding Java classes and interfaces, the following formatting rules should be followed:

 

No space between a method name and the parenthesis "(" starting its parameter list

 

Open brace "{" appears at the end of the same line as the declaration statement

 

Closing brace "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement the "}" should appear immediately after the "{"

Jeg fikler litt i C++, og må si at jeg synes det er best å ha brackets til funksjoner på egne linjer, mens brackets til if's, loops etc, rett etter siden disse kan nestes.

 

for eksempel;

 

int Min_Funksjon()
{
       for(int i = 0; i < 10; i++) {
               if(i == 2)
                       cout << i;
       }
}

 

Om man alltid skal ha brackets på egne linjer, så har det en tendens til å bli mer luft enn kode spør du meg.

[Nervetattoo]

Hva med å lage et verktøy som automatisk reformaterer koden din til god kode, etter hvilken template du selv ønsker. Hadde ikke vært så dumt.

Alle har litt forskjellige måter og skrive koden sin på, med tanke på mellomrom/tab osv.

 

Det er jo ikke umulig og lage et verktøy som leser gjennom kode of forandrer den til den måten du liker og lese det på.

 

I et miljø hvor man er flere kan man da kode helt på sin egen måte for så å oversette det over til standarden etterpå.

 

Om noe slikt ikke finnes kan jo noen her sette i gang og lage det

Et hverktøy ville jo mest sannsynlig kun fungere for et språk da det må vite om alle funksjoner osv for å kunne formatere riktig.

[epsil]

Hva med å lage et verktøy som automatisk reformaterer koden din til god kode, etter hvilken template du selv ønsker. Hadde ikke vært så dumt.

Det beste forskjønningsprogrammet for PHP er antakelig phpCodeBeautifier, som bl.a. lar en reformatere koden i henhold til PEAR-kravene (som jeg er meget uenig i på et par punkter, men det er en annen sak). De kommersielle Macromedia-programmene Dreamweaver og Homesite skal også inneholde funksjoner for forskjønning av PHP- og HTML-kode.

 

Det er jo ikke umulig og lage et verktøy som leser gjennom kode of forandrer den til den måten du liker og lese det på.

Nei. PHP-programmerere som finner et slikt prosjekt interessant kan for øvrig se på Beautify PHP, som selv er skrevet i PHP.

[jorgis]

I tillegg finnes også Tidy HTML, men det har mindre med programmering å gjøre.

Endret 23. september 2004 av jorgis

[PT]

Mens vi er inne på fin kode; hva synes dere er den beste måten å skrive ut HTML-kode på (mer enn bare en linje eller to)?

[jorgis]

Regner med at du tenker på hvordan HTML skal printes fra PHP eller lignende. HTMLen skal selvsagt skrives ut som om den skulle vært skrevet for hånd. Du skal ikke gjøre samme tabben som microsoft.com gjorde, og printe alt på en linje. Del det opp skikkelig, og bruk Tidy hvis du ikke gidder å formatere ting selv.