I recently held a presentation about Clean code at Sogeti and thought i’d recap the important parts in a post. The slides can be found on prezi.

The length of a method
A method should be as small as possible, about 3 to 6 lines of code.  The method should never be more the 10 lines of code. It should also only do one thing.

Names
The name of a method should explain what the method does, and this gets simple since the method should only do one thing. Don’t be afraid to make the method name long, make sure to use a naming convention that allows multiple words in it.

The name of a variable should explain what the contents of the variable is.
Bad name:

Int d; //Elapsed time in days

good name:

int =  elapsedTimeInDays;

Do not use any abbrevations, they might be simple for you to understand but when another developer comes into your code he might not know what the abbrevation means.

Arguments
A method should not accept more than three arguments, if you go over that number maybe you should think about making an object that contains these arguments as a property. 

Don’t use out arguments. When we read code we usually dont expect information to comeback from the arguments.

Don’t use booleans as arguments. if you do the method you’re writing will probably do more than one thing, depending if the boolean is true or false. And if you se a call to a method like this:

DeleteEmployee(“Bob”, false, true);

you will have to go into the method to know what it does with the true and false, instead of continue reading.

Comments
Do not comment code. The method name should explain what the method does. A comment will probably not get updated when the code is changed therefore the comment will be outdated and only confuse other developers. If you se outocmmented code just delete it. If you need it later it will always be in the version control.

If, else, while, foreach and try catch
The body of a if/else, while foreach and try catch should always be one line long and it should call another method. This is to keep the method small and the code will document itself with the methodname. Examples:

if(myBool){
    callToMethod();
}
else{
    callToAnotherMethod();
}

try{
    DeleteCustomer();
}
catch(Exception error){
    logger.log(error);
}

Do not return null
If a method encounters a problem and you decide to return null you’re going to have a lot of null checks in the code that calls this method. This is unnecessary, instead return a variable that is empty, for example:

List<Employee> employees = getEmployees();
if(employees != null){
    foreach(employee in employees){
        employees.raiseSalary();
    }
}

if getEmployees() would return a empty list of employee when an error occured in that method we wouldn’t need to check for null and our methodcall could look like this:


List<Employee> employees = getEmployees();
foreach(employee in employees){
    employees.raiseSalary();
}

These are only a few tips from clean code, i recommend you buy the book or take a look at Robert C. Martins code-cast about clean code.

När man arbetar med kod är det bra att följa standarder och stilguider för att kunna samarbeta eller lämna över ett projekt.
Nedan följer en lista på kodstandarder, konventioner och stilguider för diverse språk. Guiderna från Google är ganska omfattande och kan vara ganska svåra att ta sig igenom då de bara innehåller text rakt upp och ner, men är ändå bra ifall man vill kolla upp något specifikt för det språket man intresserar sig av.

Php + zend

Google Javascript styleguide

Google jSON styleguide

Google Objective-c styleguide

Google XML styleguide

Till .NET och Visual studio finns även två plugins som ser till att man skriver korrekt, de heter ReSharper och StyleCop.

I föregående inlägg har jag också skrivit om att hålla sin kod ren.

Följer du några kodstandarder, konventioner och stilguider som passar in i listan?

Efter att ha jobbat som systemutvecklare i ett år nu har jag märkt hur viktigt det är att ha kodstandarder. Med tipsen som Robert C. Martin ger i nedanstående video får man kod som är mer läsbar, lättare att komma tillbaka till efter att man påbörjat något annat projekt, och lättare för andra utvecklare att ta över.

Hur lång ska en metod vara?
På 80-talet skulle en metod vara så lång att den fick plats på skärmen. På den tiden fick man plats med 24 rader varav 4 av dom användes av programmet man utvecklade i. Idag får vi plats med hundratals rader. Martin anser att metoden ska vara så liten att den endast gör en sak, och att man då kan hålla ner radantalet mellan 3 till 10 rader.

Metodnamn
Se till att metodnamnet förklarar vad metoden gör och den ska endast göra en sak. Var inte rädd för att namnet ska bli för långt, se till att använda en namnkonvention som tillåter flera ord i namnet.

If, else, while-satser, foreach och try catch
Koden i en if, else, while-sats, foreach och try catch ska vara max 1 rad lång och kalla på en annan metod. Detta för att hålla metoden liten och för att man dokumenterar vad som händer med hjälp av metodanropets namn.

Hur många argument ska en metod ta emot?
Det idealiska antalet argument en metod har är 0, och max är 3. Över detta antalet ska man se till att man passar runt ett objekt med värdena i istället.

Outargument
Använd inte out-argument alls. Man är van vid att man skickar in argument i en metod och tar emot det som returneras av den. Normalt förväntar vi oss inte att information kommer tillbaka genom argumenten.

Booleans i argument
Använd inte booleans i en metods argument.
Då kommer metoden med stor säkerhet göra mer än en sak. En sak ifall du passar in true, och en annan ifall du passar in false.
Även anropen till denna metod kommer bli svår att tolka. Martin använder exemplet DeleteEmployee(“Bob”, false, true); Man måste gå in i metoden för att se vad den gör beroende på de booleans man skickar in.

Kommentarer
Kommentera inte koden, metodnamnet ska förklara vad metoden gör tillräckligt bra. Kommentarer riskerar att bli utdaterade när man gör ändringar i metoden och lurar utvecklaren som kommer tillbaka till metoden efter en tid. Martin beskriver kommentarer som lögner just för att de sällan uppdateras när metoden uppdateras.

Bortkommenterad kod ska tas bort direkt. Den är bara i vägen. Den finns fortfarande i versionshanteringen och går att hämta ut när du vill.

Variabelnamn
Använd inte förtkortningar i namnen på variablar. Använd samma princip som i metodnamn