Uncle Bob quips in the introduction to Code Cleanliness that when your code is being reviewed, What if the reviewer angrily shouts “What the fuck is this shit?” When you write strong words, you’re writing Bad Code. If censors casually spit out a few “What the fuck?” “That means you wrote Good Code. This is the only measure of code quality — “What the fuck?” every minute. Frequency.

Clean code is hard to write in part because bad code is so easy to write. There are plenty of opportunities to make bad code when you’re trying to get things done quickly, when you’re sloppy, when you ignore security, when you name things arbitrarily, when you have too many parameters, when you nest too much, when you don’t change comments in time, when you violate rules, when you repeat yourself, and so on. Clean code is only possible if you take your code seriously and understand what makes it stink.

Writing code is similar to writing articles to some extent. Good articles must have good readability, and writing code is the same. Only beautiful and clean code can have good readability. Writing readable code isn’t just about keeping meaningful names. If you want to be a better programmer, there are a lot of things you need to be aware of when writing code. For example:

  1. Specify the location of local variables
  2. Make the function as short as possible
  3. Where possible, the caller is placed above the called
  4. Keep your code well-formed
  5. Write a function that only does one thing
  6. Do not take more than three function arguments
  7. Exposed time series coupling
  8. Use exceptions instead of returning error codes

In addition, there are many design principles to keep in mind, such as:

  1. Open and Closed Principle (OCP)
  2. Demeter’s rule
  3. Dependency Inversion Principle (DIP)
  4. Single Responsibility Principle (SRP)
  5. Richter’s Substitution Principle (LSP)
  6. Do not repeat (DRY)
  7. You won’t need it (YAGNI)

Of course that’s not enough. It’s not riding a bike. Learning to write clean code takes a lot of work.

There are a lot of things you need to keep in mind and follow when writing clean code, but it’s not about following rules and being rigid, it’s about the beauty of simplicity, the beauty of code. The code Clean Way, the way to write great code, is all about trying to Keep It Simple, Stupid. Judge of a person to write the code, not look at its code is more complex, but if he had put the abstracted things complicated and simple way to describe it, in addition to the code’s attitude is also important, most of the time we do not write the code from the beginning of perfect, when we need to make a prototype quickly, Or code looks great at the beginning, but the existing design can’t meet the new requirements, if no design changes, then the code will become ugly, if you love what they are doing, and believe in the beauty of the code, then you will have enough power to reconstruct it, perfect it, rather than destroy the structure makes the code rot.

To keep it simple, to pursue it simple, I think this is the zen of coding, a state of pursuing authenticity. This zen is evident in Python’s design philosophy. Let’s type “import this” into the Python interpreter to see the classic Python zen.

  • Beautiful is better than ugly. Beautiful is better than ugly.
  • Explicit is better than implicit. Explicit is better than implicit.
  • Simple is better than complex. Simple is better than complex.
  • Complex is better than complicated. Complex is better than difficult.
  • Flat is better than nested.
  • Sparse is better than dense.
  • Readability should be valued.
  • What was once a white matter? Special cases aren’t Special enough to break the rules. While practicality trumps purity, exceptions do not override the rules.
  • Errors should never pass silently. Unless explicitly silenced. Mistakes should never slip away unless they are explicitly silenced.
  • In the face of ambiguity, refuse the temptation to guess. In the face of unclear definitions, resist the temptation to guess.
  • There should be one — and preferably only one — obvious way to do it. One way, preferably only one way to do one thing.
  • Although that way way not be obvious at first unless you’re Dutch. This may not be obvious at first, but you’re not the father of Python.
  • Now is better than never. Although never is often better than right now. Doing is better than never, but doing right now is sometimes worse than not doing at all.
  • If the implementation is hard to explain, it’s a bad idea. If the implementation is hard to explain, it’s a bad idea.
  • If the implementation is easy to explain, it may be a good idea. If the implementation is easy to explain, it’s probably a good idea.
  • Namespaces are one honking great idea — let’s do more of those! Namespaces are a great idea, let’s use them more!

The Tao focuses on method and Zen focuses on attitude. Let’s combine the two and be a programmer with ambition and strive to be a software engineer.

Now that you have seen here, don’t stop to click a like, star, github, no advertising, make a friend 🤝.