Forskjell mellom versjoner av «Hvordan skrive et godt program»

Fra mn/ifi/INF1060
Hopp til: navigasjon, søk
(Flyttet makefile til 'andre tips')
Linje 4: Linje 4:
  
 
Her er en liste over viktige ting å huske på (i mer eller mindre tilfeldig rekkefølge)
 
Her er en liste over viktige ting å huske på (i mer eller mindre tilfeldig rekkefølge)
 +
 +
 +
== Strukturer koden skikkelig ==
 +
 +
En del legger veldig mye kode i main-metoden. main-metoden har kun en funksjon, og det er å starte programmet.
 +
 +
Main bør kun inneholde logikk for å sjekke kommandolinjeparametre, samt kall på metoder som faktisk skal utføre oppgavene.
 +
 +
Strukturerer du programmet ditt skikkelig, blir det veldig mye enklere å holde det ved like, samt å debugge når problemer oppstår.
 +
 +
Når du strukturer bør du lage metoder med avgrensede oppgaver, og ikke la metoden gjøre andre oppgaver i tillegg.
 +
  
 
=== Unngå tett kode ===
 
=== Unngå tett kode ===
Linje 91: Linje 103:
  
 
Det aller viktigste er å skrive kode som ikke trenger kommentering. Hvis man gir metoder og variabler fornuftige navn er det ofte ikke nødvendig å kommentere så mye. Kommentarer skal kun skrives når det er nødvendig, så jo mer selvforklarende koden er, jo færre kommentarer trengs.
 
Det aller viktigste er å skrive kode som ikke trenger kommentering. Hvis man gir metoder og variabler fornuftige navn er det ofte ikke nødvendig å kommentere så mye. Kommentarer skal kun skrives når det er nødvendig, så jo mer selvforklarende koden er, jo færre kommentarer trengs.
 
 
== Ikke legg all koden i main-metoden ==
 
 
En del legger veldig mye kode i main-metoden. main-metoden har kun en funksjon, og det er å starte programmet.
 
 
Main bør kun inneholde logikk for å sjekke kommandolinjeparametre, samt kall på metoder som faktisk skal utføre oppgavene.
 
 
Srukturerer du programmet ditt skikkelig, blir veldig mye enklere å holde det ved like, samt å debugge når problemer oppstår.
 
 
Når du strukturer bør du lage metoder med avgrensede oppgaver, og ikke la metoden gjøre andre oppgaver i tillegg.
 

Revisjonen fra 11. okt. 2010 kl. 08:12

Hvordan skrive et godt og ryddig program

Det finnes utallige meninger om hvordan et godt C-program skal se ut, men enkelte retningslinjer er de fleste enige om.

Her er en liste over viktige ting å huske på (i mer eller mindre tilfeldig rekkefølge)


Strukturer koden skikkelig

En del legger veldig mye kode i main-metoden. main-metoden har kun en funksjon, og det er å starte programmet.

Main bør kun inneholde logikk for å sjekke kommandolinjeparametre, samt kall på metoder som faktisk skal utføre oppgavene.

Strukturerer du programmet ditt skikkelig, blir det veldig mye enklere å holde det ved like, samt å debugge når problemer oppstår.

Når du strukturer bør du lage metoder med avgrensede oppgaver, og ikke la metoden gjøre andre oppgaver i tillegg.


Unngå tett kode

Mange skriver kode uten å bruke plass, dvs. tomme linjer for å skape naturlige avgrensninger mellom kodeblokker.

Ha alltid minst én tom linje i følgende tilfeller:

  • Mellom metoder.
  • Mellom deklarasjoner av lokale variabler og den første “statement”-setningen i en metode.
  • Før en ny kode-blokk.
  • Mellom logiske oppdelinger av en metode.

Kun et statement per linje

Mange liker å bruke flere statements per linje:

if (1 == 1) {return 1;} 
else {return 0;}

Slik koding bidrar ikke til annet enn å gjøre programmet vanskeligere å lese. Det er med andre ord en uting.

Kommentering

Hvordan man skal kommentere kode er ikke lett å vite alltid, men her kommer en liste over nyttige tips. Mange tenker at "Nei, kommentere koden gidder jeg ikke for jeg skjønner jo hva som skjer." Det er to problemer med denne tankegangen;

  1. Andre skjønner det ikke.
  2. Det skal ikke mange dagene/ukene til før du ikke skjønner det du heller.

Det er bare en ting å gjøre; lære seg å kommentere skikkelig, og her kommer noen tips:

Dokumentér hver metode

Hva er denne metodens oppgave? Beskrivelsen skal være så kort og konsis som mulig. Her skal også argumenter samt retur-verdi dokumenteres. Her er Java-doc-syntax helt fint hvis man foretrekker det. Formen på forklaringen skal ikke være "Jeg gjør slik og slik". Det skal forklares hva metoden gjør.

/* 
  Takes two integers as arguments and return their sum. 
  - arg1: First integer 
  - arg2: Second integer 
  - return: The sum of the to integers 
*/
int add_numbers(int num1, int num2) { 
   return num1 + num 2; 
}

Kommentér paragrafer

Del koden opp i logiske deler og kommenter disse.

// Verify that all numbers are positive. 
// Negative values are set to zero. 
int i; 
int zero_count = 0; 

for (i = 0; i < length; i++) { 
    if (array[i] < 0) {
        array[i] = 0;
        zero_count++;
    } 
} 

// Calculate the average of the positive numbers 
int average = 0; 
 
for (i = 0; i < length; i++) { 
    average += array[i];
} 
average = average / (length - zero_count);

Kom til poenget!

Ikke skriv mer enn det som er nødvendig for å forklare poenget.

Don’t insult the reader’s intelligence

Unngå å forklare selvfølgeligheter:

if (a == 5) {// if a equals 5 
    counter = 0; // set the counter to zero
} 
fclose(file); // Closing file descriptor 
// Output space printf("\n"); 

Det er bortkastet tid å skrive unødvendige kommentarer, og det gjør det vanskeligere å lese koden.

Lesbar kode

Det aller viktigste er å skrive kode som ikke trenger kommentering. Hvis man gir metoder og variabler fornuftige navn er det ofte ikke nødvendig å kommentere så mye. Kommentarer skal kun skrives når det er nødvendig, så jo mer selvforklarende koden er, jo færre kommentarer trengs.