As Software Developers, we need to look at the bigger picture, as it's not just about writing code and hope it works. So what is the bigger picture?
A client is paying for a software product that we will be producing. A client is anyone who requires our software development services, could be our employer or someone paying us to develop an application. The client has trusted us to deliver good quality software. It's up to us to deliver the product in the best way possible. The client is dependent on us to produce good quality software that works on production with minimum issues.

Why we need to practice clean code

Poorly written code can cause immeasurable production support, debugging, and can collapse the entire application. Poorly written code can cause frustration and stress on Software Developers and the client’s alike.

"Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way." Robert C. Martin

Clean code empowers us to provide the client with quality software. We don't just write code for things to work, We do it right the first time. We need to keep in mind Robert C. Martin's words: "Even bad code can function."

Clean code is:

• Simple

• Readable

• Easily understandable

• Without duplicates

• Efficient

Five clean code practices that are simple to implement

1. Making classes cohesive

Good planning and design play a substantial role in clean code. We shouldn't just start writing code, we should first design our classes based on use cases. A class should only have a single responsibility. Once a class starts having more than one responsibility, we probably need to start thinking about abstraction and inheritance. Let's say we have a Dog class that contains Cat functionality, that is a hint we need to extract a Cat class and create an Animal parent class. When classes are cohesive, they're independent of each other. It is easier to add new functionality without touching existing functionality.

2. Making methods cohesive and small in size

A method should have fewer lines, single responsibility, and only do one thing. We should not update a dog in the same method that we save a dog. Methods with fewer lines are simple to read, understand, and maintain. Methods with fewer lines make it easier to write unit tests. Methods with a single responsibility are reusable.

3. Making methods and variable names descriptive

Variable and method names should be descriptive. The name of the variable and method should denote its meaning. We should be able to look at the method name and know what the method does. We should avoid one letter variable names such as "a,b,x,y." We should withdraw from abbreviating variable and method names. The names should be simple to understand. We rather use a long variable or method name that is easy to understand than a short name without meaning and difficult to read.

4. Refactoring

"Leave this world a little better than you found it." Robert Baden-Powell

When we check out code from the code repository, we have a responsibility to make the code a little better than we found it when we check it back in the code repository. We should continuously refine existing code. Refactoring reduces complexity and improves the quality of code. Refactoring keeps existing code organized and manageable.

5. Writing unit test

We should try to write a unit test for every public method. Unit tests improve the quality of our code and verifies our code works as expected. To be able to refactor code continuously, we need to have unit tests in place. Unit tests ensure we are not breaking our code as we refactor. Unit tests tell us the behavior of our code has not changed.

We are not just Developers, we also are professionals, therefore we need to do a professional job. It is a myth that great Developers write complex code, in fact, great Developers write clean code. We should be able to look at the code and understand what it is doing without debugging. We will save a lot of time for our teammates. I will leave you with the below quote from Robert C. Martin.

"clean code is a promise made to one's self: "I will do a good job. I will not rush. I will write tests. I will go fast by going well. I will not write crap. And I will practice so that I can be a professional." Robert C. Martin