Clean Code – Part 01

Have you thought about what people think after they read your software code? I’m not only talking about people that you hang with in these days. Remeber the first company where you worked, will your code be praised? Whould the guy who works with you get a psychotic freak-out if he tries to read and understand the last code you wrote? What do you think, about the quality of the code that you are refactoring today? Which skills levels would you give to the creator of that code?

The question that remain: “After people read our code, would they have us as a reference for development?” (ouch!).

For this to happen, we should do some good practices and costumes while writing our “Daily If”. This subject is huge, so I have to split it.

As a start point, we will use a system that summarizes soccer matches. A little brief about it: “Soccer Show is a system whose objective is to summarize soccer matches. The system must have: date/hour of the scheduled matches, matches place of teams that will be playing (and the players), the result, the sum of the cards applied by the officials”.

1 – Classes

  • It’s a good choice to name the classes as nouns. At our sample system, we could identify: Match, Stadium (match place), Team, Officials and Players. This will help you to think and understand what’s going on. It will give you a better vision of the application context. Imagine if we had declared Stadium as a String at Match class. If later we were asked to add the Stadium capacity, we would create another attribute in Match, the class would start losing its “Cohesion”, who else should know the capacity of the people in the Stadium, but the Match.
  • Classes not in plural. Tell me what will pass through your mind after reading this class name: “Players”. A collective of players is a probably answer. It’s pretty obvious, but, I have seen this happening at some applications. When I asked why, no one told me the reason of that name (they did not know it). Naming your class correctly will bring more clearness to your class purpose.

2 – Methods

  • Methods name should indicate a verb. After we read the method name, we already can have an idea of what this method will do. By Sample:

    What does this piece of code? What does it returns? Then you take some time getting in the class, opening the method to read the code… Imagine if the code was like this:


    After reading the method name (with the verb), you already have an idea of its return object, even more, a possible method behavior.

  • It’s a good idea that each method contains only one behavior. Imagine if you invoke a method to get the total of present audience at the match:
    List presentAudience = match.getTotalPresentAudience();

    After you invoke the method you get this message:

    Exception in thread "main" main.DaoPublicException
      at main.DaoPublic.updateTotalProfitMatch(
      at main.PresentAudience.getPresentAudience(
      at main.match.getPresentAudience(
      at main.Principal.main(

    But, why a method that updates the matches profit is doing at this simple GET method? Your method must be “Cohesive”. Even, if there is no option, as last choice, change the methods name so the developer that will use the method will be aware of what might happen. (I know, its ugly, but…)

  • Indent: This is like “The First Developer Rule”. The problem is that each developer has its own preference, and sometimes it does not fit at the company indent pattern. One thing is for sure, I do not know which indent pattern you will adopt, but, please, take one. Right below we get two codes where it’s easy to see which one is easier to read:
            public int calculateScoredGoals()
        {int total = visitorTeam.getScoredTeam() +
                return total
      public int calculateScoredGoals() {
        int total = visitorTeam.getScoredTeam() + houseTeam.getScoredTeam();
        return total;

    It does not matter what kind of indent you will adopt, just chose one that makes the code reading easier not only for you, but for your entire company.

  • We should not keep returned attributes from methods if it will not be accessed later. Let’s imagine an update method which returns a list with the objects that were updated:
      public void updateMatchDate() {
        //... Some code
        List expelledPlayers = DaoFactory.getDaoMatch().updatePlayers(expelledPlayers);
        //... More code, but none of them accessing expelledPlayers

    What’s the motive of creating the list? What for? Just invoke the method and it’s done. The list will be updated and you will not have an allocated object without reference.

This was the first post about this subject, much more are coming! Leave your opinions bellow so we might chat about it. I love to learn with other people experiences.


Leave a Comment