Imagine you are working on a project that you already write a lot of code for it , but this code is messy , bad naming bad functions , you rush that code you need to ship the code into production , but something bad happen a bug came and now you need to fix that bug. But your code is messy and it's hard to edit that code.
Now let's move to the other case , imagine you are reading a code for someone else maybe in company or open source project , how hard it is to modify a messy code?
What happen to code? why it start good then transform into tragedy?
You can know how a code is bad by looking at faces of the people who read this code.
A rigid system is a system that when you need to change it in a place it force you to adjustments in other areas in the system.
and those adjustments let you do adjustments in other place. And the programmers start to spin around them self changing hundreds of modules their and their to make the system run again.
Fragile systems are those who broke when you make a change in one place. A simple change can make a malfunction to the entire system. Those systems are hard to estimate because they hard to predict.
When a system is fragile users and managers notice it , they see strange malfunctions in places that used to work.
An inseparable system is a system that composed of modules that can't be separated and reused in other purposes. It's hard to make a system reusable because designers fail to make a reusable design , and Developers are in hurry to finish it by taking shortcuts , and those shortcuts are by using inseparable modules.
Inseparable systems are hard to unpredictable you never know if you can reuse them , so it's hard to make estimates.
A bad code is the code who hard to read , hard to understand , hard to change.
Did you ever write a bad code before? of course you did we all did , maybe it's because of the frequent change of requirements , the hurry of customers , stupid managers , impossible schedule.
Well we can't blame any one else it's
we , we programmers write bad code. And we write a bad code because we feel the urgent of the dead line so we rush , we tell that we are going to fix it later, but hell nah we don't.
as my professor in the university once said
The hurried , walk slowly - Ghazi ayyoub
Every one think that they can go fast by rushing , but that's an illusion you can't rush code and go fast.
have you ever watch a sushi chef making that sushi ? he have all the tools in front of him , as soon he deliver order he clean the workspace because he know that this is the way to go fast.
Bjarne Stroustrup, inventor of C++:
I like my code to be elegant and efficient. The logic should be straightforward and make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.
Grady Booch, author of Object-Oriented Analysis and Design with Applications:
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designers’ intent but rather is full of crisp abstractions and straightforward lines of control.
“Big” Dave Thomas, founder of OTI and 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. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since, depending on the language, not all necessary information can be expressed clearly in code alone.
Michael Feathers, author of Working Effectively with Legacy Code:
I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you are led back to where you are, sitting in appreciation of the code someone left for you—code written by someone who cared deeply about the craft.
Ward Cunningham, inventor of Wiki and Fit, co-inventor of Extreme Programming. The force behind Design Patterns. Smalltalk and OO thought leader. The godfather of all those who care about code.
You know you are working with clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.