Clean Code Part 1

The capacity to constantly improve your techniques of creating code while working on more projects or through refactoring is one way to tell if you’re evolving as a software developer.

The sole purpose of this series is to teach developers some tricks to writing clean code.

What is a clean code?

Clean code, in my opinion, is software that is simple to comprehend, write, read, and maintain. Every developer who wants their code to have the important features outlined above should make it a habit to do so. One thing about the software industry is that it evolves and improves with time. For example, the old waterfall model, which was used by many teams, not just software developers, but also in other sectors, is still alive and well. However, as time passed, the same process changed or improved in response to 😂 mankind’s desire to make life easier, resulting in processes such as the iterative waterfall model, evolution model, iterative model, prototype model, agile, and so on.

We can see the same influence rippling across every aspect of our lives; we are evolving humans, after all, and many software developers have worked hard to enhance the way we write code. These approaches or tactics were created in response to a slew of challenges that developers encountered after completing their programming. The following are a few of the issues that were raised:

1. Inability to understand the code after some time.
2. The inability of new software recruits to understand and maintain the code they came to meet.
3. Code becomes complex to build upon it when new features have to be added.

And the list goes on and on. For these reasons certain patterns have been and solutions have been given to them, and these are what we consider best practices. They are not strict to follow, but following them will go a long way to help you. Some of the best practices include;

1. Writing good comments, which explains what is actually happening in your code.
2. DRY. Which simply means do not repeat yourself. I will expound on this in the next part of this series.
3. SOLID(Single Responsibility, Open-Close, Liskov Substitution, Interface Segregation, and Dependency Inversion principle).
4. Using Descriptive names for classes, functions, variables, etc.
5. Read functions should return something and write functions should return void.
6. A function shouldn’t be both read and write.

In the next part of the series, I will explain with examples what each part means.