Code Cleaning

Take care of your codebase. Keep it clean. A good codebase will enable you to create more great solutions for your demanding customers. If you do not take care of your codebase, then it will rot and your projects (and company) will probably fail.

There is only one way to keep it in a healthy state, follow the boys scout rule: always leave the codebase in a better state than you found it. Whenever you make a change, try to write clean code yourself and clean up surrounding code.

I just gave a lightening talk at Smidig 2008. My talk was about a selection of techniques for improving existing code, how to keep your codebase healthy and why you should do it. Here are the slides and a recording of the talk.

This entry was posted on Friday, October 10th, 2008 at 7:59 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

One Response to Code Cleaning

  1. Nils Harald Berge says:
    October 24, 2008 at 1:53 pm

    There is something wrong with one of the core clean values. Oncle Bob
    is a wise man, Clean Code a great (and important!) book. Olve is with
    no doubt a brilliant programmer and it-professional. So i’m
    struggeling a bit with this.

    The rule of keeping functions small i can live with, but to keep them
    very small (and seemingly at all cost), well this just does not add
    up. “They should do one thing, they should do it only”. I’m not sure
    if this really is a general rule that will help keeping code clean.

    The problem that really should be addressed IMHO is the basic priciple
    of encapsulation. Is stuff where it’s supposed to be? Is the domain
    reflected by the object? Is the methods reflected by the domain? Is
    your view of the object limited by the domain? Lets take a look at the
    try/catch block example from the slides: is it better to factor out a
    method:

    private void logError(Exception e) {
    logger.log(e.getMessage());
    }

    i don’t think so. This is (a small step to) breaking encapsulation of
    the Logger. Why is it better to break up the pay method to three
    different methods? I find the pay method mutch easier to read. In fact
    i would rather compact it to make it even more pleasing to the eye:

    public void pay() {
    for (Employee e : employees)
    if (e.isPayday()) e.deliverPay(e.calculatePay());
    }

    now thats a method! One glance at it and you have the whole story. I’d
    mutch rather se a cupple of well written methods that fits well with
    priciples of encapsulation (and hence the domain), then a zillion
    methods where you really must dive deep to get the details.

    … my 10 cents