Checklista för snygg javakod

Detta är inte en komplett checklista, men jag la upp den i hopp om att ni kanske kan få några tips från den.

Checklista...

  • Har varje klass ett väl avgränsat ansvarsområde? Till exempel, en klass bok håller reda på vad en bok heter, vad den kostar och hur många sidor den har, eventuellt någon metod för att beräkna pris per sida.
  • Speglar namnet på klassen dess uppgift? En klass som har hand om utlåning av böcker heter inte Bosse utan Bibliotek eller något motsvarande. Detta trots att just din lokala bibliotikarie heter Bosse! Varför? Jo, det är inte allmänt kännt att Bosse lånar ut böcker, en person som försöker förstå din kod kommer antagligen bli förvirrad av ditt namnval på klassen.
  • Kan en person som aldrig sett din kod förut förstå vad en klass har för funktion genom att bara se namnet på klassen? - Om inte, skulle du kunna ändra namnet på klassen så att det går att ha en intuitiv förståelse för dess uppgift?
  • Skapar din konstruktor en instans av objektet som är färdig att användas, eller måste du anropa andra metoder efteråt som läsInFrånFil("helalistan.txt")? Om det senare, varför inte flytta in det metodanropet i konstruktorn?
  • Har metoderna namn som speglar vad de gör snarare än hur det gör det? En metod som kontrollerar att procenten summerar ihop till hundra bör kanske heta kontrolleraAndel snarare än summera. Dess uppgift är att kontrollera att alla andelar blivit inmatade, vilket vi är mer intresserade av att veta än hur den gör det (genom att summera). Lata människor (och trötta assistenter) läser bara metodhuvudet, namnvalet är din chans att kort sammanfatta metodens uppgift! Koden blir också mer lättläst när metodanropen ser vettiga ut.
  • Ligger metoderna i rätt klass? Detta kan ibland vara lurigt. Försök avgränsa klassens ansvarsområde. Använder metoden instansvariabler från en annan klass, fundera på om den kanske inte bör ligga i den andra klassen istället.
  • Är din kod lättläst? Har du gott om luft i koden och kommentarer som förtydligar? Det kan vara bra att skriva en mycket kort kommentar ovanför varje metod, vilken förklarar vad den tar för indata och vad den retunerar.
  • Testa på en kompis, se om han eller hon tycker det går snabbt att förstå hur ditt program fungerar? Behövde du förklara någonting, fundera då på att lägga till en liten kommentar i koden eller byta metod- eller variabelnamn?
  • Snygg kod är lätt att läsa och har en logisk struktur.
  • Static ska användas sparsamt, helst ska bara main-metoden vara static. Har du static variabler, fundera på om du inte kan göra om dem till instansvariabler.
  • Våga vägra klassmetoder (static).
  • Indentera din kod! Det ökar läsbarheten, och du kan lättare se var en for-slinga eller metod börjar och slutar. Testa Meta+X och sedan indent-buffer för att göra det automatiskt.
  • Slå på färgerna i emacs, det underlättar felsökning för dig.
  • Är du osäker? Fråga en assisten! Vi är här för att hjälpa er.

Punkterna ovan är sådana jag kom på spontant när jag satt och spånade, de är alltså inte sorterade i någon speciell ordning. Förhoppningsvis kan de dock ge några tips om hur man kan tänka för att snygga upp koden lite.


Från kurshemsidan anno 2004:

Krav på J-uppgiftslösningen

Utöver kraven på funktionalitet som finns i uppgiftslydelsen gäller detta alltid:

Programmet ska vara användarvänligt och presentera sig vid programstart. Tydliga instruktioner ska ges på skärmen. Det ska vara lätt att förstå vad programmet skriver ut. Det är tillåtet att anta att indatafiler är felfria om inte annat anges i uppgiftslydelsen. Ingen felkoll behöver göras för att upptäcka om indatafiler verkligen existerar.

Programmet ska vara kommenterat upptill med författare, datum och ev revisionsdatum. Överkommentera inte programmet i övrigt. Tänk på att det är kvalitet och inte kvantitet på kommentarer som räknas.

Programmet ska vara vettigt uppdelat i klasser och metoder, och metoder ska inte vara alltför långa (max en skärmsida). Det ska vara lätt att i efterhand gå in och förstå och ändra i programmet. Robust, flexibelt och lättläst är nyckelord.

Varje klass, instansvariabel och metod ska vara försedd med kommentarer. Ange vad klassen och variabeln representerar och vad metoden gör. För metoder bör man också ange vad indata (parametrar) och utdata (retur-värde) betyder. Det ska räcka att läsa kommentar och metodhuvud för att förstå hur en metod ska användas.

Namn på klasser, variabler och metoder ska vara vettiga. Alla deklarerade namn ska vara på samma språk, liksom alla kommentarer (engelska namn och svenska kommentarer är OK). Koden skall vara snyggt formaterad.

Nästan identiska kodstycken ska inte upprepas. Gör i stället generella klasser och metoder. Inför inte i onödan begränsningar. Inför konstanter för sådant som man kan tänkas vilja ändra framöver (om man skulle vilja arbeta vidare med din lösning) och för tal som inte ska ändras och går att beskriva med namn.


Tillbaka till Johannes Prgibio04 sida (email)