Clean Code - Chapter 1️⃣

Play this article

One of the key skills in the armoury of a good software engineer is the ability to write clean code and not only that but also to identify bad code and transform it into a good one.

Reasons for having bad code

  • One emphasis on delivering code faster

  • One is tired of existing task and wants to jump onto the next item

  • One feels code cleanup and refactoring is boring

We say that we will clean it up tomorrow and we all know about tomorrow, it never comes. But for once try and take the time out the clean the bad code and you will feel a surreal sense of accomplishment.

Cost of owning a mess

Bad code that is not cleaned up timely can end up being so huge that eventually there is no way possible for anyone to stick their head in it and do the cleanup. Moreover, the adverse effects of it such as slowness in development, longer time to understand the existing code and code failures due to poorly written older code are inevitable.

As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero.

  • Bad code requires redesign and makes it difficult to maintain

  • Poor attitude and weak stomach lead to bad code

  • One can never meet deadlines by writing messy code.

The only way to go fast is to keep your code clean

A programmer without "code-sense" may be able to differentiate bad code from good code but will not have any idea about how to fix it.

A programmer with "code-sense" would be able to look through the messy code, see options and variations and choose the best variation.

A programmer who writes clean code is an artist who can take a blank screen through a series of transformations until it is an elegantly coded system.

What is clean code?

Bjarne Stroustrup

  • Elegant, pleasing to read

  • Efficient

  • Less room for bugs to hide

  • Minimal dependencies, ease of maintenance

  • Complete error handling

  • Optimal performance

  • Does one thing well

Grady Booch

  • High readability

  • Crisp abstraction

"Big" Dave Thomas

  • Easy to enhance by other developers

  • Has unit and integration tests

  • Meaningful names

  • Provides one way (not many) to do things

  • Minimal API

  • Literate code

Michael Feathers

  • Looks like written by someone who cares

Ron Jeffries

  • Contains no duplication

  • Expresses all the design ideas

  • Minimizes the number of entities (classes, methods, functions)

  • Abstract common use cases

Ward Cunningham

  • Looks like what one expected

  • Beautiful code makes the language look like it was made for the problem

The Boy Scout Rule

It's not enough to write the code well. One has to ensure it is kept clean over time.

Leave the campground cleaner than you found it.

This wraps up the very first chapter of this book.
See you in the next one soon.