Cleaning Your Coding with Clean Code

*not* this kind of cleaning

Clean code is one of the most important aspects of software development, as the project is developed rapidly, the use of clean code is important to balance the workload of the development. Clean code is also implemented on Agile Methodology, based on the book ‘Clean Code: A Handbook of Agile Software Craftsmanship’ by Robert C. Martin.

“Clean code is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.” — Robert C. Martin

Robert explained the importance of clean code very well in his book, he implied that the code we write is not intended only for the computer but also for humans and that’s what makes clean code an important aspect. When writing clean code, you are not only helping yourself but also your co-workers, in order to collaborate better.

Clean code does not have a definitive meaning, as it is subjective and every developer has a personal take on it. But to make it simple, on a level surface, clean code means that one’s code is easy to understand and easy to change. Based on that sentence alone, we can understand that clean code makes everything easy:

• Easy to understand the execution flow of the entire application
• Easy to understand the role and responsibility of each class
• Easy to understand what each method does
• Easy to extend and refactor
• and more…

We will look at the most important principles to improve code quality based on Robert’s book.

Naming Variables

Naming good variables could help give information about the variable itself, so you or someone else can understand its significance. Instead of inserting the information of what the variable is or what the variable is used for in a comment, it is better to put it in the variable name itself.

Bad example :

var a; // elapsed time in days

Good example :

var elapsedTimeInDays;

Besides naming good variables, a programmer must also avoid disinformation and noise words. Noise words are words that don’t offer additional information and better to be removed. Some popular noise words are The, Info, Data, Variable, Object, and Manager. If you have a class named UserInfo, you just can remove the ‘Info’, resulting in the class name to be just User.

Using pronounceable names is also a must in order to ease other members to understand that variable.

Bad example :

const yyyymmdstr = moment().format(“YYYY/MM/DD”);

Good example :

const currentDate = moment().format(“YYYY/MM/DD”);

Lastly, avoid using numbers or single-letter names for naming a variable. Strive for a good variable name by making it searchable and named constants.

Bad example :

if (student.classes.length < 7) {
// Do something
}

Good example :

if (student.classes.length < MAX_CLASSES_PER_STUDENT) {
// Do something
}

Making Functions

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” — Robert C. Martin

The quality of one’s code is critical if they want their application to be stable and easily extensible. So, when writing functions, we have to avoid the following negative properties:

• Functions that are lengthy
• Functions that are difficult to understand and test
• Functions names that are vague
• Functions that are fragile

Before and after making a function “clean”. https://dev.to/gonedark/writing-clean-code

As Robert stated, functions must be small. By small it means that it should not reach 200 or 300 lines because those kinds of functions are not optimal. They should not be longer than 20 lines and mostly less than 10 lines. Functions should be making as few arguments as possible.

Block and indenting: By following the rule of keeping functions small, it implies that we should avoid long if, else, switch, and while statements, because they could make functions messy. If it is necessary to use them, try to use only one or two lines and that line should be a function call.

Bad example :

function greetings(timePhase:string) {
if (timePhase === “morning”) {
console.log(“Good Morning”);
} else if (timePhase === “afternoon”) {
console.log(“Good Afternoon”);
} else if (timePhase === “evening”) {
console.log(“Good Evening”);
} else {
console.log(“Good Night”);
}
}
// calling
greetings();

Good example :

function printGreeting(greeting:string) {
console.log(greeting);
}
function greetings(timePhase: string) {
let greeting = ‘Good’ + timePhase;
printGreeting(greeting);
}

Embracing clean code means one function must do only one thing. If a function does more than one thing, the function must be split up into more functions.

Don’t Repeat Yourself (DRY) is one of the methods to avoid duplicate code. The DRY principle states that duplication in logic should be avoided and eliminated. DRY is important if you want flexible and maintainable software.

https://www.slideshare.net/mariosangiorgio/clean-code-and-code-smells

What to avoid next is side effects. If a function offers nothing other than entering or returning values, it will create a side effect. Side effects are mutations or actions that happen in our code environment that we cannot make account of.

https://www.slideshare.net/myposter_techtalks/concepts-of-clean-code-adapted-for-javascript-techndrinks-myposter

To anticipate errors in our program, error handling is important. When encountering an error, throw exceptions rather than return error codes. Each exception that you throw should provide enough context to determine the source and location of an error, containing informative messages.

Lastly, variables that are declared and not used anywhere can be described as a dead code, and must be removed. Dead code can be caused by incomplete factoring. Dead code must be avoided because it is as bad as code duplication, maybe even worse because it offers nothing and only making the code not optimal. If there’s an unused code, prioritize to delete it instead of “commenting” them. One of the ways to detect and get rid of dead codes is with linter tool on the programmer’s IDE. Besides that, linter is also useful for layout formatting: arranging codes to be neat so it can pleasing to the eye.

Beware the dead! https://twitter.com/intelsoftware/status/925432702781837312

Conclusion

Clean code must be recognized and implemented by programmers to reach a maintainable, extensible, and readable program. By using clean code, it offer programmers benefits such as the ease to find and fix new bugs (without breaking the current functionality), add the code base to implement new requirements, read the code without spending too much time thinking, and many more.

References :

Clean Code: Writing Functions or Methods

What is Clean Code and why should you care?

Clean Code: Error Handling

Clean Code and The Art of Exception Handling