Clean Code

This is summary of chapter 1 of Clean Code written by Robert C. Martin.

There will be code

One might argue that soon all code will be generated instead of written. That programmers simply won’t be needed because business people will generate programs from specifications.

It’s totally nonsense. We will never be rid of the code, because code represents the details of requirements. At some level those details can’t be ignored.

Level of abstraction of programming language will continue to increase. Number of domain specific language will continue to increase. But it will never eliminate code. All the specification written in these high level and domain specific language will be code. We may create languages that are closer to the requirements. But we will never eliminate necessary precision, so there will always be code.

Bad Code

In late 80s, a company wrote a killer app but after sometimes release cycle began to stretch. Bugs were not repaired from one release to next. Load times grew and crashes increased because code was mess as they added more and more features code got worse and worse until they simply couldn’t manage it any longer and the company went out of business a short time after that.

This was cost of bad code. We’ve all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We’ve all said we’d go back and clean it up later. But we never did.

The Total Cost of Owning a Mess

Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero. So management hires more and more staff but new staff is not versed in design of system. So, now team is under pressure to increase productivity. So they all make more and more messes, driving productivity towards zero. So spending time keeping your code clean is not just cost effective; it’s a matter of professional survival.

Attitude

What’s the reason of bad code. We may blame that requirement changed against current design, we may blame tight schedule and blather about stupid manager. But the fault in ourselves. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion. It is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes. The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times.

What is clean Code

Bjarne Stroustrup, inventor of C++ :- Code should be elegant and efficient. elegant means code should be pleasing to read. The logic should be straight forward. Error handling should be complete which includes memory leaks, race conditions, inconsistent naming. The code should pay attentions to details. Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details.

Grady Booch, author of Object Oriented Analysis and Design with Applications :- Grady emphasises on readability. Clean code should read like well-written prose. Like a good novel, clean code should clearly expose the tensions in the problem to be solved. It should contain only what is necessary. Our readers should perceive us to have been decisive.

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy :- Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. Code, without tests, is not clean. No matter how elegant it is, no matter how readable and accessible.

Michael Feathers, author of Working Effectively with Legacy Code :- 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.

Caring of our code is very important. It’s like a building with broken windows looks like nobody cares about it. So other people stop caring. They allow more windows to become broken. Eventually they actively break them.

Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C# :-

In priority order, simple code:

• Runs all the tests;

• Contains no duplication;

• Expresses all the design ideas that are in the system;

• Minimises the number of entities such as classes, methods, functions, and the like.

The next time you write a line of code, remember you are an author, writing for readers who will judge your effort. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.

So we can say that a clean code contains no duplication, does one thing, it’s expressive, easily maintainable and readable, contains tiny abstraction, runs all the tests, smaller, and efficient.