We can all write code and make stuff work but when we look back at our own code, we realize how bad it was and how far we have come. Good, you are already evolving. but this series will take your learning up a notch and make it even better.
Sometimes code can become a mess and the cost of owning a big mess can be huge. Developers fear from making new changes as it might break something else. How can we solve that?
The answer is clean code. It means that the code should be simple enough to understand and make further changes without fear of breaking something else. i.e readable and maintainable. It requires you to give extra care and time while writing the code but its beneficial in the long run because a software is never complete and changes with time. so lets jump to how YOU can write clean code.
Any name? No. You are not writing the code for yourself. you are writing the code for others so when your team or your future self reads the old code. They don’t pull their hairs trying to figure out what it does and unintentionally wasting their time. Code consists of a lot of variables, classes and Methods. and everything has a name. the names need to be consistent and explain what the code does. Some examples of consistent names can be found here. Let’s look at an example:
int m; // elapsed time in minutes
m reveals nothing. It does not evoke a sense of elapsed time, nor of days. We should choose a name that specifies what is being measured and the unit of that measurement:
This makes the variable easy to understand and reveal its exact purpose. we don’t even need to write extra comments as the code is self explanatory.
Lets take a look at another method:
The method name
getThem gives us no idea what the method does. someone using that method has to go inside that method and go thorough the whole code to understand what it does.now we refactor the below code to:
This is the same code as above but the name
getEvenNumbers gives us clear idea what it does and we don’t have to go inside the code to see what it does. With these simple name changes, it’s not difficult to understand what’s going on. This is the power of choosing good names.
consider below code:
And compare with:
Notice the difference in readability of both methods? now we know what argument is being used for what purpose just by the signature of method.
One should not use any non standard abbreviations that may confuse others. using
no instead of
number is tolerable as everyone knows what it means.( I do not encourage this as it may get confused by “NO”) but we should not create our own abbreviations which might confuse someone else. such as while writing dates a variable called
Date creationTimestamp; is better than
Date creationdmY; as the former can be pronounced in a conversation.
One might easily grep for
MAX_CLASSES_PER_STUDENT, but the number 7 could be more troublesome. Searches may turn up the digit as part of file names, other constant definitions, and in various expressions where the value is used with different intent.
Once again compare
now the code is more searchable in case any change need to be done.
Proper Spellings are also a part of making things searchable. a simple misspelling of a word
Heirarichy can make that world impossible to find in the whole codebase.
Methods should have verb or verb phrase names like
save. Accessors, mutators, and predicates should be named for their value and prefixed with
is according to the javabean standard.
Address address= person.getAddress();
When constructors are overloaded, use static factory methods with names that describe the arguments. For example,
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
is generally better than
Complex fulcrumPoint = new Complex(23.0);
People who read your code are still programmers so you can still use some domain specific terms. The name
MainActivity means a lot to a person familiar with android. which programmer would not know what a
Map is in programming terms?
The hardest thing about naming things that it may take time sometimes and varies with personal cultural background. Most of the time we don’t memorize the names instead we use modern IDEs to search and find them. Follow some of these rules and see whether you don’t improve the readability of your code. If you are maintaining someone else’s code, Modern IDEs has made is very easy to refactor things. It will pay off in the short term and continue to pay in the long run.
The Principles in this post are taken from a book I read recently, Clean Code: A Handbook of Agile Software Craftsmanship. I highly recommend that you should read it if you want to dive even deeper.
If you enjoyed this story, please click the 👏 button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter. The next part will have clean functions, Stay tuned. Until then keep clean coding 😉