Software Engineering

Clean Code: A Handbook of Agile Software Craftsmanship – Chapter 1

This is the first article of my series of notes on the book Clean Code: A Handbook of Agile Software Craftsmanship by  Robert Cecil Martin.

I will read this well-known book one more time and write simultaneously my notes, comments and important quotes from the book. This is a 443 pages book so I am planning to make it around 10 times shorter.

My Foreword

Since this is my second time reading this book, I want to give you a quick heads up.

Most of the accusations, tips and comments in this book are rather utopic. You might say that,
“Yeah you wish!” or “it’s impossible”,
but just keep an open mind and try to get the most.

You and I both know that the developer market is so fast and everyone is replaceable and you don’t want to lose your job because of your clean code discipline.
I once called “a clean code enthusiast” by one of my former colleagues, like this is supposed to be a passion, so I can imagine how most of you will react to the author from time to time.

Keep up the good work and prepare yourself to the day you use this information.

Chapter 1

There Will Be Code

You can think that writing clean code is not an issue anymore because as programmers, most of what we do is finding suitable libraries, frameworks, drivers and tools written by another programmer. So the only requirement will be to use generators and tell those generators their specifications.

But we will never converge to a point where one can manipulate computers in a free manner, without knowing how computers work or even how to code.

There are multiple reasons to why but as the level of abstraction of our programming languages increase, the complexity of our requirements increases as well.

Any person with a decent computer and stable internet connection can create a blog website like freethemalloc.com (i even have the tutorial), with zero previous knowledge in an hour. Sure, coding will be eliminated for this kind of peculiar jobs but the complexities will always increase and there will always be code.

Bad Code

Uncle Bob tells a real story about how bad code caused future bugs and caused the failure of a company. It was not important how.

The Total Cost of Owning a Mess

As the mess builds, no change is trivial anymore. Small changes break huge functionalities, productivity decreases.

The Grand Redesign in the Sky

Eventually, the team of devs and engineers demand a redesign. But if your team/company has a bad attitude, as the time goes, first ambition and eager of redesign disappears and the redesigned architecture becomes a slightly better version of the legacy version. – still a mess-

Attitude

Why does good code rot so quickly into bad code?

  • Bad assessment of requirements. We changed requirements so much that it jeopardized the initial design
  • Bad assessment of deadline and manpower.
  • Bad influence of marketing (team) on product quality.

They are all correct, valid reasons to messy codebases. But the real reason is:
We are unprofessional.

9/10 cases, decision-maker is a non-tech person. It is highly expected by your manager to push you to be faster. But when things go south, you are responsible for every bad thing related to code.

When people look at your code 5 years later, your name appears on git-blame , not your managers. You must be able to bargain about time and human power.

I can hear you saying that it is easy to say, no one cares about your opinion on these kind of things etc., but no one will ever care if you don’t step up.

Just do prep work, explain step by step and bargain your requirements.

it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.

Uncle Bob

What Is Clean Code?

Bjarne Stroustrup, says that the code should be elegant and efficient. Elegant is a very general and heavy word but I think the message it conveys; is that when you look back to your work after a couple of hours, it should be pleasing to read.
He also mentions the importance of details. Error handling, race conditions, memory leaks and so on…

Dave Thomas and Andy Hunt, say bad code is like a house full of broken windows. If you don’t take care of it, people will start breaking your windows too, throw garbage around and so on. One broken window starts the process.

Grady Booch, says clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

Continue Reading Chapter 2: Meaningful Names here!



2 thoughts on “Clean Code: A Handbook of Agile Software Craftsmanship – Chapter 1”

  1. Pingback: - freethemalloc

Leave a Reply

Your email address will not be published. Required fields are marked *