Simple tips on writing clean code
So I have been reading the book “Clean Code- A Handbook of Agile Software Craftsmanship” of Robert C. Martin Series for the last couple of months beside my regular job, and found this book very informative and didactic. I personally think every software developer should read this book by his/her own and try to implement the instructions while coding. In this article I actually would like to write about some basic good practices that every developer should follow and make it as their coding norm.
- Later equals never
We all write messy codes and feel relief when we see our program works. Then we look at the mess we made and think that we will refactor it some other day. But the truth is that day never comes!So refactor it before making it more messy in future.
2. The Boy Scout Rule
“Leave the compound cleaner than you found it.” This is the rule followed by the Boy Scout of America. This rule completely aligns to our profession.We should leave the code a little bit cleaner than we found it. The cleanup doesn’t need to be big. A simple name change of a function or variable, break up a function which is little bit longer, eliminate a duplication will do a lot. Remember, code that gets better as time passes won’t simply rot to bad code.
3. Use Intention-Revealing Names
We use names everywhere in our code. So care should be taken while naming any variable,function or class. Picking up good names takes time but it will save more than it takes. The name of a variable,function or class should answer all the big questions.It should reveal what it does, why it exist,how to use it. A name shouldn’t require any comment to reveal its intent. For an example
is not a good choice for naming a variable. Here r reveals nothing. You can use rentPerMonth as the variable name instead. It is more informative and helps other developers understand easily.
4. Avoid Disinformation
We as a programmer must avoid leaving false clue that obscure the meaning of our code. Do not refer to a group of person as a personList unless it is actually a list. Instead use personGroup or simply persons. Because list has some other meaning to the developers.
5. Make meaningful Distinctions
We as a programmer create problems when we write code solely to satisfy the compiler or interpreter. For an example as we can not declare two variables with same name in same the same scope, we might be tempted to change one name in an arbitrary way. Moreover it is not good to use number series for naming variables. Does it make any sense if you find someone wrote int a1,a2,a3; to define three different variables? Your code should say what you meant to do.
6. One word per concept
Pick one word for one abstract concept and stick with it. Don’t use get,fetch,retrieve as equivalent methods of different classes. It will confuse the developers. How do you remember which method goes with which class?
7. Use solution domain name
We are programmers. People who will maintain our code will also be programmers. So feel free to use computer science terms, algorithm names or pattern names. It is not a good choice to draw every name from the problem domain when they already know the concept by a different name. Naming a method getShortestPathUsingDijkstra() is more convenient when you are implementing dijkstra algorithm. It reveals what it does and why it exist.
8. Use Problem domain name
When there is no “programmer-eese” for what you are doing, use the name from problem domain. At least programmers who will maintain your code can ask the domain experts to understand the meaning or business. Separating solution and problem domain concept is very important. Code that has more to do with problem domain concept should have name drawn from problem domain.
9. Function should be small
Functions or methods are like building blocks of our code. Writing them cleanly is how we can make our code base cleaner. While writing a function or method there are two rules you should follow. The first rule of the function is that they should be small. The second rule of the function is that they should be smaller than that! A function shouldn’t be more than 20 to 30 lines long. Horizontally each line shouldn’t be more than 80 characters long.
10. Do one thing
While writing you classes or function you have to keep in mind that you shouldn’t put more than 1 responsibility on there shoulders. Your class or function should do one thing. They should do it well. They should do it only.
11. Don’t always comment
You can think that by commenting each and every function’s and variable’s purposes, you are making lives of the future developers easy. But actually you are polluting the code base and making it more noisy, clumsy and misleading! You should understand that nothing can be quite so helpful as a well-placed comment. And nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation. Don’t comment where you can simply rename the variable or function such that it tells the story.
