Series Clean Code - Overview (Part 2)

Continue the topic in the previous section about Clean Code in the previous articles, I'll talk about 7 reasons why we need to know about Clean Code.

1/ There will be code

Many people may argue that somehow, writing code will no longer be a problem any more, they told that:

• We just only care about models and requirements. That's enough.
• Our term is going to be the end of writing code.
• Programmers will no longer necessary it because business customers will create their own programs by entering technical specifications. 

Not okay! We will never escape the code, because:

• The code represents the specifics of the requirement.
• Requirement details, at some levels, can not even be ignored or abstracted, but must be explicitly specified.  
• Required details of the following requirements to the only that the machine can be executed, primary to the program.
• One specific description is code. 

Code in the end is actually the language we express the requirements:

• We can create programming languages closer to the requirements.
• We can also create tools to help you analyze and assemble requirements into standard structures.
• But we will never get rid of the essential accuracy - and therefore, the code will always exist.  

In the future, there will always be code.

No matter how advanced technology is, for programmers, coding:

• Is not replaceable. 
• And will be associated with yourself for a long time until quitting. 
• Code, code, code forever, ...  

2/ Bad code
 

In fact, a company in the late 1980s wrote an app called "killer":

• Very popular, and a lot of professionals have bought and used.
• But then the release cycle of the new version increasingly thin. 
• Errors not fixed after each release.
• The application is more and more "heavy" or "suspended". 
• Finally the company had to stop the business shortly after.

What happened? 

• Rushed to market and created a huge mess in the code. 
• When adding more and more features, the source code is getting worse. 
• Until really can not manage the source code anymore. 

=> The bad code itself has shut down the company. 

Why do we write "bad code"? 

• Try to do it fast? hurry? 
• There is no time to do better because of the deadline, because the boss will be angry if the time to clean up without finishing. 
• Maybe because it was too tired and just hoping for it to finish soon, so even though the code is messy but run without any errors as well.
•  Tell yourself to come back and clean it up later. 
• LeBlanc's Law: Later equals never

3/ The total cost of owning a Mess

The messy code will make the job slow down considerably:

• At first, the team performed very quickly at the beginning of the project. 
• Each time you change, break some other part of the code. 
• Each time add or edit, the system is confused, messy, ... 
• Over time, the mess grows bigger. 
• Productivity decreases and asymptote to 0.

Attitude

Why good code quickly became bad code?

• The original requirements were altered to break the original design.
• Work schedule is too tight to do everything properly.
• Stupid management, stiff clients, useless marketing categories, and even "toilet cleaners.

No, bugs are in us, programmers!

For example, suppose you are a doctor and have a patient asking you to skip some hand-washing while preparing for the surgery because they take too long. How would you handle it?

The duty of a professional programmer is to protect his code, even though the deadline is still clean, in front of the manager, because the manager, as well as the patient, knows nothing about the clean code, as well as the price paid for a series of dirty code. 

The Primal Conundrum

Want to schedule clean code, because the messy code will make you slow down immediately.

The only way to meet the schedule, the only way to go that fast is to keep your source code as clean as possible.

The Art of Clean Code

Writing clean code is similar to the way we paint a picture, most of us can recognize pictures that are drawn beautiful or bad, but recognizing beauty does not mean we know how to paint beautifully.

Writing clean code is an art, you can simply look at and recognize where the code is clean, where is the dirty code, but does not mean we know how to write clean code.
 

Clean code writers are an artist who can paint an empty screen into an elegant code system.

To write clean code you have to have code sense on cleanliness, which can be practiced through the process of applying thousands of small techniques into code writing.
 

When it gets to know where the code is clean dirty code, and can turn dirty code into clean code, get the feeling and choose the best change.

What is clean code?

Every programmer has a different clean code statement: 

• Bjarne Stroustrup, author of The C ++ Programming Language: "is elegant code (beautiful, subtle and simple) and effective ..., is code doing a good job."  
• Grady Booch, author of Object Oriented Analysis and Design with Applications: "is simple, direct and easy to understand.""Big" Dave Thomas, founder of OTI,  
• Godfather of Eclipse: "is code that can be read and improved by another developer, not necessarily the original author." 
• Michael Feathers, author of Working Effectively with Legacy Code: "is the code written by a mind person."
•  Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C #: "is a code that minimizes duplication, does a thing, is extremely clear and builds up small abstraction models." 
• Ward Cunningham, creator of Wiki, Fit, co-founder of eXtreme Programing: "is the code where every code you read is exactly what you expect."

4/ Schools of thought

In the martial arts, each founder has a different school, disciples of each sect are immersed in the teachings of the founder, the disciples after graduation can set up their own job, and no one of all the schools, that's all right.

Therefore, this book is only an experience that the author has practiced, which provides the necessary teachings and brings certain benefits, it does not mean absolute right.

Other books by other professional programmers also provide other benefits that it provides, and can learn from them good things.

5/ We are authors

 

Each author has their readers. And you are also an author, each line of your code is written for reading readers.

If you want your work to be smooth, you want to finish it quickly and write code easier - first make it easy to read.

6/ The Boy Scout Rule

 

Scout law: "Leave the campground cleaner than you came."

Clean code is not something too big, simply: 

• rename a variable for better 
• splitting a large function into smaller functions 
• remove duplicates 
• cleans up complex if statements

7/ SOLID Principles 

• Single Responsibility Principle (SRP) 
• Open Closed Principle (OCP) 
• Liskov Substitution Principle (LSP) 
• Interface Segregation Principle (ISP) 
• Dependency Inversion Principle (DIP) 

About SOLID principles, I'll have another articles told about it.

The book does not promise to help you become an artist, a good programmer. It can only show you the process of becoming a good programmer, the tricks, techniques, and tools they use. Please follow next topic of Clean Code - Meaningful Names...

See you in next chapter about Meaningful Names in Clean Code...