Clean Code Series #1 - Concepts

Part I - The Art of Clean Code

It's pretty evident that for us, as software engineers, best coding practices are essential. Most of you know that the concept of Clean Code is one of the most fundamental ones. In 2008, Robert C. Martin organized a compound of thoughts around this idea of code simple and well-organized code in his book, Clean Code: A Handbook of Agile Software Craftsmanship.

If you are familiar with the concepts, feel free to skip this lecture. Otherwise, if you are starting in the fantastic world of software development, this is a synthesis of Uncle Bob's book's first chapter.

One important concept is that code is the language in which we ultimately express the requirements. We will never eliminate the code itself, regardless of how much technology and automation we can create to develop a new application. Starting from this principle, we can infer that our job is of such importance to make a good application (internally and externally speaking).

They are 4 characteristics that define a bad code:

1º Rigidity: the tendency of a system to resist change. Because of the high dependency between the classes, functions, modules, you should change many places to fix a single bug or add one new behavior.

2º Fragility: when the system is fragile, a bug repair can add a malfunction in another part of it that is not related to its changed part.

3º Inseparability: because of the high coupling between the parts that compose the code, the various parts cannot be used independently. It's impossible to reuse without causing duplication in part of this code.

4º Opacity: the capacity of the code to be organized in a way that you have no idea about what's the intention of this function, method, class. Everything is so cumbersome that you enter a vortex and waste so much time just to understand the flow, the proposal of that code.

Book's Law:

The software in many companies is written in a rush, and poorly written code was the cause of the solution's failure. The maintenance becomes so tricky that every new requirement stretches the time to release until it's impossible to keep up delivering new updates.

According to Fred Brooks in this book The Mythical Man-Month - Essays of Software Engineering:

"Adding manpower to a late software project makes it later"

The most important reasons for this effect are:

- It takes time for people to become productive (learning curve).

- Communication can be more difficult when the number of people in the team increases.

- The divisibility problem: "nine women can't make a baby in one month".

- If the code is messy, the tendency of the new people is to follow the "pattern" replicating the errors.

And Uncle Bob explains how it can be dangerous the creation of a Super-Star team to redesign the entire system, maintaining the older one in parallel. The cause: "The Neverending Story Problem", where the new system never can keep up with the older one.

What is a Clean Code for You?

Bjarne Stroustrup - the creator of C++:

"Clean code is pleasing to read. It should be efficient and focused (each function, class, module exposes a single-minded attitude that will not pollute by surrounding details)."

Grady Booch - one of the inventors of UML:

"Clean code should be simple and direct. It should contain only what’s necessary."

Dave Thomas - father of the Eclipse Strategy:

"It’s not just a matter of the code being readable. It should be easy to change as well."

Michael Feathers - author of Working Effectively with Legacy Code:

"The importance of care, when you write the code."

Ron Jeffries - author of Extreme Programming Adventures:

"No duplications, high expressiveness, simple abstractions."

Ward Cunningham - inventor of Wiki:

"The routine is pretty much what you expected when you read. The code also makes it look like the language was made for the problem."

Uncle Bob - author of Clean Code:

"We are constantly reading old code as part of the effort to write the new code. If you want code to be easy to write, make it easy to read."

Robert Stephenson Smyth Baden-Powell - the father of the Scout Movement:

"Try to leave this world a little better than you found it."

The Conclusion

How can programmers be professionals and not bend to managers, marketing teams, or customers? We should tell our story. It's a parallel with a doctor and a patient, that doesn't want to waste much time waiting for the doctor to wash his hands. Should the doctor accept this and not wash his hands before the surgery? Obviously not!

The only approach to stick with the deadline is to keep the code as clean as possible at all times. A messy code will slow you down during the project, and you will miss the deadline for sure.

Try to leave this world a little better than you found it, even if it's a small change: variable name, breaking a significant function into two.

The Entire List of Chapters