Clean Code – Part 02

>Good night everyone, everything ok?

Let’s continue with the subject of keeping our code clean? The first part you can find in here: Clean Code – Part 01

Today we will be talking about scoped variables and attributes.
PS.: Every time I write attributes, I will be referring to both cases, OK? To scoped variables (methods parameters, definitions of variables inside of loops), and to classes attributes. By doing this I will not be repeating attributes/scoped variables all the time. It will make the text smaller and easier to read.

  • Use camelCase at attributes names – this is a basic tip and you will see it around every time. Makes the reading easier and it is adopted by a lot of other development languages. Some samples would be:
        String disapprovedStudent;
        double totalDivide;
        boolean isManager;

    An advantage is that it’s easier to read in camelCase then:

        List player_own_goals;
        List playerOwnGoals;

    A disadvantage would be for long attributes names:

    Map allYellowHousesFromTheBlock;

    That means, use it but don’t abuse.

  • List name on plural – why put a name like: “listPerson” if you just name it as “people” it will give the same idea? There is a huge difference between person and people by the meaning of those words. Keep this concept in mind and you shall see how legible your code will be. Lets see a sample of how a “foreach” would be:
        List houses = new ArrayList();
        // adds the houses from the block at the list 
        for (House house: houses) {

    Notice that when you read the name “homes” from the list it is clear that we are talking about a group of “home”. When more often this naming “pattern” be applied to your system, clearer will be to those that read it the attribute meaning and how it is used at the method.

  • We shall name the attributes with real names and ye spoke ones, names that provide a “self-explanation”. Think in case you find this kind of attributes naming:
    public class Car{
        //... some code
        boolean caCra;
        //... some code

    What that attribute suppose to mean? What it would be its purpose? How do you say that? Imagine you calling your coworker, and when you try to explain what you are doing, he asks you: “Ok, but which attribute are you talking about?”! How you would you say that?
    Having an attribute with a name straight, objective and “ye spoke” you already can imagine what it means, and when you refer about it with someone, it would be easier to be spoken and the one that is listening you, just by hear it, it might be able to remember of that code. Oh yea, that attribute name how would be if named right?

    public class Car{
        //... some code
        boolean isCarCrashed;
        //... some code
  • If you see the code below, be careful. It might give you a lot of misunderstanding:
        int value1, value2, value3;
        // ou 
        String name1, name2, name3;

    What could possibly mean the one, two or three? Notice that at any moment the attribute let us know where it would be used or in which way it will be used. The code gets harder to understand. In case you got some bad luck getting a nested if/else/while with those kinds of attributes, go get a coffee because you are going to have a very long afternoon… Imagine this situation:

        String str1, str2, str3, str4;
        //... some code
        str4 = str3.substring(4,8) + str1.concat(str2);

    Now, imagine if the code had been written like this:

        String userLogin, userPassword, lastLoginDate, userAccessKey;
        //... some code
        userAccessKey = lastLoginDate.replaceAll("/", "-") + userLogin.concat("-" + userPassword);

    We are able to understand what this code is doing just by the attributes name. By doing this inside of a method with a good naming… Make a perfect combination that will make every developer, which reads your code, happy. I have seen cases that semantically (it was an OO study) which it would not have another possibility instead putting numbers at the end like 1 and 2. If you have in mind the same concept and perception, that the project would not loose its cohesion and its definition if the attributes receive the numbers in the end (1 and 2) go ahead and implement it.

  • Attributes names must make sense to the context that the attributes are being used. Always when you read an attribute name you must understand it in that code, for that specific context:
        //... some code
        int total = 0;
        for (Trade tradedBall : tratedBalls) {
            total += tradedBall.getTotalTratedItens();
        for (Trade tratedHelmet : tratedHelmets) {
            total += tratedHelmet.getTotalTratedItens();
        StockFacade stockFacade = FacadeFactory.getStockFacade();
        //... some code in the same method
        //... 15 lines after
        double totalSpent = financialFacade.calculateSpentValue(spentValuesWithEmployees + (valuePerIten * total));
        return totalSpent;

    What is that “total” that came from nowhere at the final sum? Where does its value come from? Which role it has on that method? Now, imagine if instead of “total” its name was “totalTradedItens”. Read that code again changing the “total” name for the suggested name.
    This is the difference of always give a name that has the same value at the context where it is used.

  • Do not specify the attributes type in the front of its name. It is very usual you find “intAge”, “strName”, and “dtBirth”. You might ask: “What’s wrong with it?” Remember that one of the good practices is that the attribute name should “self-explain”? Put the attribute type in front of the name has some advantages:
    • Stimulate some bad attribute naming: it is easier think in put “dtBirth” then “birthDate”. And the idea of “sex-explain” names would start to fail. Others weird names could appear like: dtBir, dtNatDe (naturalDeathDate).
    • Type abbreviations at attributes names: it would not take long to see names like: “strName”, “stName” or “nmName” (if the attribute name was just “name” it would be ok). So far nothing extravagant, but imagine if your software has a javascript and then you start to see: “cbDtSt” or “txtNmFi”. What would be your reaction? Would you know how to explain each one? Believe in me, I’m not overreacting, I’ve seen attributes with that name.
  • Have you ever thought about short attribute names and easy to type? Suppose that in your software you got an attribute named “allAliensFromTheEntireUniverse”. Now think if you have to type that attribute name every time… Would not be easier if was just “aliens”? It is easier and we could understand that it is a list. Don’t you have times that you are doing that exciting code and when you have to type the giant attribute you think: “Come on, should I have to type it again?”? With IDE’s “self-complete” it is easier to type those attributes name, but imagine someone having to choose between 5 names every time instead just typing it if a small attribute name was. Remember, an attribute name should not back away people.
  • Space between your attributes – A code that has a lot of calculations and methods calls with out spaced attributes, it is a headache! Let’s see a sample:

    A code it’s cleaner when it has space between its attributes:

    total = salesPerDay(today) - (COMMITTEE_PERCENTAGE * vendors + totalSoldItens);
  •  Avoid sending null attributes: sending null attributes it’s the root of all nullPointers! Just imagine if you are invoking a method that you never use before, but they told you: “Go ahead, put this invoking at your method and send it to the client. You can trust because this method it’s bulletproof!” But what they never told you is that you could not send a null value. When this happen (null pointer) the trust from your client to your software would be shaken.

Well folks, I hope this article might help you.

This subject will be continuated.

Leave a Comment