Writing clean code

There are a few reasons why our code smells:

There is a consensus that clean code can help drive productivity in a software development company. When we are trying to build a prototype, a proof of concept, or a minimum viable product, the code may begin as a big jumble mess to get something working. But, in all cases, we should always refactor the code to be maintainable and readable in the end. So what are the characteristics of clean code?

Let’s take a look:

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent. Therefore, name elements on the basis of what they are and make it a habit to maintain a convention throughout your code. Ensure that names are pronounceable.

Boolean Names — variables or methods that return a boolean value, should start with “is”, “has”, “can” or “should”….or something similar to define the yes/no action.

Interface Names — Interfaces usually use letter “I” as prefix with name of interface. After letter I, use Pascal case.

Method Names — Methods should have verb or verb phrase names like PostPayment, DeletePage, or Save. Accessors, mutators, and predicates should be named for their value and prefixed with get, set. Also, methods should be named for what they do, not how they do it. You may change the implementation later and you shouldn’t need to refactor your consuming code because of it.

Pick One Word per Action — Pick one word for one abstract concept and stick with it. For instance, it’s confusing to have fetch, retrieve, and get as equivalent methods of different classes. How do you remember which method name goes with which class?

File Names — Your file names in source code should ideally match your class or entrypoint names. Naming things differently will cause confusion by other contributors of the code. You should always try to strive to keep them in sync.

A method shouldn’t have more than 3 to 5 arguments. This definitely isn’t a hard number but keep it as low as possible. When a method seems to need more than three arguments, you probably should wrap the them into a class.

Below, you can see how the code is cleaner by making a class out of arguments. Not only does it look cleaner, you can now easily refactor the class object without breaking the signature of the method.

Add comments only to explain convoluted thoughts. Fewer comments reduces clutter.

In the clean version, we rename the result variable to better describe what is returned, thus eliminating the need for comments since the code is self-explanatory.

Initially your code may be messy as your starting out with your thoughts and trying to get things to work. You can refactor the code, after it’s working, into smaller chunks and fewer lines, each with a single responsibility. Remember, you are writing code not only for yourself but for others that may be supporting your code.

Related posts:

Prioritize your most important tasks (MIT). Separate the most urgent from the least important. Access the value of each task in order of importance and add an estimated time for completion to your…

During this extraordinary COVID year, I turned 40. At such a milestone, it has me thinking a lot about our lives and the people in them. I have a beautiful family, a place to call home and I love the…