För länge, länge sedan jobbade jag med en junior utvecklare, som vi kan kalla för Emmoth, och hoppas på att han förblir annonym. Liksom alla som är nybörjare på ett språk ville han demonstrera att han kunde Javas nyckelord, och skapade en del intressanta konstruktioner i ett redan intressant program.

När jag tröttnade på detta skrev jag ner ett antal ord på en liten whiteboard och sa att han inte får använda dem. Detta blev “Emmoths lista”. Det lustiga att är att den håller än idag! På listan stod:

static: Det finns många anledningar till att inte använda static. De främsta är enligt mig, att det möjliggör singleton och försvårar testning. Det är väldigt sällan vi på klassnivå behöver ha en “global” variabel. Statiska variabler ställer också till det i distribuerade applikationer, då vi måste hålla kolla på att de read only.

Undantaget är så klart static final och statiska klasser (men de senare är inte klockrena heller).

protected: Åter igen… Hur ofta behöver vi detta nyckelord? I 9/10 använder folk protected felaktigt istället för default access. Eftersom jag inte heller är en vän av arv, så kommer jag med argumentet att man för att korrekt använda protected måste bygga en avancerad klasshierarki, speciellt designad för utökning, men konstig på något vis. Brrrr….

synchronized: Hur många kan direkt förklara notify/wait/synchronized? Detta nyckelord är bekvämt, eftersom vi bara behöver slaska in det i en metodsignatur, så kommer det “att funka”. Självklart finns det en massa fel man kan göra: synkronisera i onödan, synkronisera över för mycket och dynkronisera på fel sak (överkurs ).

Från och med Java 5 har vid dessutom bättre sätt att synkronisera saker på.

Object: Inte lika aktuellt nu som när listan tillkom. I gamla Javan kunde man irrirera folk genom att skriva:

List myList = ...
Object o = new Object(); // För att vara säker
o = myList.get(0); // List returnerar ju Object!
MyListItem item = (MyListItem) o;

Petigt? Ja, men den som underhåller detta måste tänka ett varv till, och för att hänvisa till en nypublicerad designprincip: Är det fult så är det fel!

I jakten på tydliga variabelnamn har den så kallade “i-variabeln” alltid retat mig. I-variabeln är den vaiabel som man använder för att iterera över ett antal element. Den kan inte missförstås, eftersom den utgör ett trivialt index. T ex:

for (int i = 0; i < 10; i++) {
    System.out.println("Hello World, and i =" + i);
}

En annan variant är iteratorn:

for (Iterator i = collection.iterator(); i.hasNext(); ) {
    Item = whatever (Item) i.next();
    ...
}

Nu är det ju så att det egentligen inte är särskilt användbart att härma skollabbar och iterera över någonting i eller j antal gånger. Oftast itererar man över en collection av någonting, och behöver man göra någonting i*j gånger finns det oftast färdiga algoritmer för detta. Det finns så klart alltid undantag, men generellt sett kommer vi väldigt långt på att ersätta i-loopar med iteratorer. Dessa kan i sin tur ersättas med Java 5:s utökade for-loopar.

Det enda användningsområde som återstår är borttagning! Av någon anledning är detta ett underskattat sätt att ta bort saker på:

for (Iterator i = collection.iterator(); i.hasNext(); ) {
    if (...) {
        i.remove();

Ofta ser man folk göra en hemmasnickrad variant av borttagning och använda olika varianter som kräver i-variabeln.

Den dag Javas loopar tillåter borttagning är i-variabelns sista fäste intaget. Fram till dess – i.remove().

Final är ett av mina favoritnyckelord i Java, och empirisk erfarenhet visar att det är ett otroligt enkelt verktyg för att skapa lite tydlighet i kladdig kod med många variabler. Givetvis är det också en förutsättning för korrekt implementation av value objects, men detta är inte dagens ämne.

Dagens ämne är final i metodsignaturer. I ett kodstycke jag arbetade med idag såg jag detta (har bytt ut lite variabelnamn för att skydda den skyldige):

public FooPK create(final BarPK barPK, final int aLongParameterName, final Integer nullableParamterOne, final Integer nullableParameterTwo) { ... }

Vad gör och vad gör inte final här?

1) Det berättar att aLongParameterName inte får ändras. Som om det gjorde någon skillnad. Java skickar ändå by value, och använder man parametar som temporära variabler, så har man större problem än ett extra final.

2) Det låter metoden bo i en annonym inre klass, vilket enligt mig är det enda korrekta användningsområdet. Så är dock inte fallet här.

3) Den säger att referenserna till de tre andra parametrarna inte kommer att ändras i metoden. Åter igen… by value.

Allt detta står i en Java-bok, och är inte lika intressant som upphovsmannens förklaring: signaturen visar tydligt att parametrarna inte kommer att ändras, alltså kommunicerar metodens avsikt, typ.

Varför är man då så småsint att man atackerar en sån liten sak? Jo, från underhållsprogrammerarens perspektiv blir koden konstig. Man måste börja fundera kring varför parametrarna är final och försöka gissa upphovsmannens intention. Det är helt omöjligt att avgöra om nyckelordet ska knytas någon extra signifikans, eller om den som skrev det hela inte var säker på hur språket hanterar parametrar. Oavsett, så stjäl det fokus från det den som underhåller koden ska göra. (Plus att metodsignaturen ser ful ut i en IDE med syntax highlight).