För att göra det lättare att hitta i koden är det bör den följa en genomtänkt koddisposition. Nedan är en vanlig disposition som används i många språk.

1. Alla import-satser placeras högst upp i filen (se också PEP8 - Imports för intern ordning)
2. Eventuella globala konstanter
3. Funktionsdefinitioner och klassdefinitioner
4. Kod utanför funktioner, t.ex. anrop till en main()-funktion och annan kod i if __name__ == "__main__": -block.

• Alla satser som består av fler än en rad ska ha en tillhörande kommentar som förklarar dess syfte. Dvs. if-satser, loopar, funktioner och metoder. Kommentaren ska inte vara en “innantilläsning” av koden den hör till. Använd rätt notation (dvs. """ för dokumentationssträngar, # för kommentarer i löpande kod, se PEP8 och PEP257).
  • Anmärkning: Kommentarskravet reflekterar inte nödvändigtvis kommentarskrav “i verkligheten” utan finns som krav i kursen för att ni ska öva er på att reflektera och skriva förklarande kommentarer. I verkligheten är det viktigare att koden är “självdokumenterande” med bra namn på variabler och funktioner, och att kommentarer bara används sparsamt när det verkligen behövs.
• Funktioner och variabler ska vara döpta på ett bra sätt, dvs. att de är beskrivande och reflekterar innehåll/funktion. Låt funktionsnamn vara verb och variabelnamn vara substantiv. Undvik namn på enbart en bokstav (var beredda att kunna motivera varför ni valt just det namnet). Se PEP8 - Naming Conventions för mer detaljer.

Här är icke-godkänd kod:

1v = 0
2q = 0
3u = [19, 21, 24, 20]
4
5# för alla element t i u, lägg till t till v
6for t in u:
7    v += t
8q = v/len(u)

Här är en godkänd variant:

1sum_age = 0
2avg_age = 0
3ages = [19, 21, 24, 20]
4
5# beräkna summan av alla åldrar
6for age in ages:
7    sum_age += age
8avg_age = sum_age/len(ages)

Minimera användningen av “hårdkodade” värden, dvs. litteraler på allehanda ställen i koden, använd istället variabler med förklarande namn.

Som tumregel kan ni tänka att om ni använder samma litteral på fler än ett ställe i samma syfte, eller om det är en sifferlitteral som inte är -1, 0 eller 1 och används rent mekaniskt (t.ex. för att stega framåt/bakåt vid iteration), så ska ni ersätta litteralen med en variabel.

En annan anledning att byta ut ett hårdkodat värde mot en variabel är för att enklare kunna experimentera med olika värden genom att ändra variabelvärden som samlats på ett ställe i koden. Om ni tänker “Men det är så svårt att komma på vad vi ska döpa den variabeln till” så ska ni tänka såhär: Det är ännu svårare för en utomstående (eller er själva i framtiden) att förstå sammanhanget om det bara står en litteral i ett sammanhang där det är svårt att komma på hur värdet kan namnges i ett variabelnamn.

Användning av hårdkodade siffervärden (även kallade “magic numbers”) ses särskilt som ett så kallat (anti-mönster)[https://sv.wikipedia.org/wiki/Antim%C3%B6nster], dvs. något man ska undvika. Läs mer om detta på t.ex. Wikipedia.

Ej godkänd kod

1kontosaldo = 2000
2att_betala = 500 - (500 * 0.1)
3att_betala += 240 - (240 * 0.1)
4kontosaldo -= att_betala

Godkänd kod

1kontosaldo = 2000
2pris_godis = 500
3pris_godispåse = 240
4rabatt = 0.1
5att_betala = pris_godis - (pris_godis * rabatt)
6att_betala -= pris_godispåse - (pris_godispåse * rabatt)
7kontosaldo -= att_betala

• Dela upp er kod i delfunktioner vid behov:
  • när ni stöter på kod som ni upprepar, bryt ut koden (lägg koden i en separat funktion/metod)
  • skicka nödvändig information som argument till funktionen och låt den returnera eventuellt resultat, använd inte globala variabler
  • dela även upp er kod i fler funktioner/metoder när den blir för lång

Som tumregler, försöka se till att era funktioner

• endast gör en sak
• inte är längre än 15 rader (gärna kortare) exklusive kommentarer