What exactly is good code? Robert Martin said it perfectly.
The only measure of code quality is how many TIMES WTF is spoken per minute
Let me explain this sentence. When I do code review, I usually have three different feelings:
- What-the-f **k — This code is not necessary
- What-the-f **k — This guy is so smart
- What-the-f ** K — What the hell is this
So what influences our first impressions when we look at the code?
This is a neat and beautiful piece of code.
Being able to write neat and beautiful code is the mark of a good engineer.
It is Clean and Beautifully written code.
And writing clean and beautiful code is the mark of a GREAT softwarecraftsman.
There are two keys to learning this great business: knowledge and work.
Knowledge will teach you how to become more professional in patterns, principles, practices and heuristic methods. But it takes a lot of reading and writing, a lot of practice and a lot of hard work.
In short, learning how to write clean code is not an easy task. You have to work at it. You have to practice again and again and again and again and again and again and again and again and again and again and again and again and again and again until you get it right. There are no shortcuts to this process.
Here are some tips on how to write clean and beautiful code.
“What is in a NAME”
Kendrick Lamar said this:
If I were to tell a true story, I would start with the name of the story.
If I’m gonna tell a real story, I’m gonna start with my name
We name functions, classes, parameters, packages, etc. We also name source files, directories. In short, good naming is probably the most important factor in keeping code clean when it comes to writing code.
Your name should show your intention. Choosing a good name can take some time, but if you name it arbitrarily, you’ll waste more time understanding it later. So make your naming as sensible as possible, and people who read your code will thank you for it.
Keep in mind that naming variables, functions, and classes should answer three questions: why they exist, what they do, and where they are used.
This requires not only good descriptive skills, but also an understanding of the cultural context across borders. No one is better equipped to teach you that than yourself.
“Functions should DO ONLY ONE THING.”
What we call the principle of single responsibility.
Louis Sullivan described it perfectly
Formal following function
Form follows function.
Each system is built with a specific programming language. Functions are usually verbs and classes are usually nouns. Functions usually appear on the first line in any programming language, and the essence of writing clean code is to write clean functions.
To write neat functions, you should first follow two golden rules:
- Functions should be as short as possible
- The function should only do one thing
This means that your functions should not have nested structures. So functions should have no more than one or two indentation levels, which will make your code easier to read, understand, and digest. In addition, we need to ensure that the statements in the function are all at the same level of abstraction.
Mixing different levels of abstraction in a function often makes the code very confusing and difficult to manage. A good engineer sees a function as a story to be told, not just code.
They often use the capabilities of their programming language of choice to build richer, more expressive, and more concise blocks of code. This makes them better storytellers.
“Comments do not make up for bad code”
Venus Williams sounds the alarm:
Everyone has their own commentary, and that’s where the rumors start.
Everyone makes their own comments. That’s how rumors get started.
Comments are a double-edged sword, and being in the right place can provide the most useful assistance to others. On the other hand, wasting space to add useless comments can clutter up your code even more. If comments provide incorrect information, it can be disastrous for the code.
In short, comments are a necessary evil. Why is that? In general, the older the comments are, the more difficult it is to maintain. Many programmers are notorious for modifying code without maintaining comments.
The code changes a lot over time, but the comments don’t change with it, which is a big problem.
Keep in mind that clean code with a few comments is far better than messy code with a lot of comments. Don’t waste time explaining the mess you’ve made, but spend some time cleaning it up.
Formatting Code is always a priority
Robert C. Martin said
Code formatting is all about communication, and communication is a top priority for professional developers.
Code formatting is about communication, and communication is the professional developer’s first order of business.
The above statement may not be widely accepted, but it is the most important quality of a good developer. Formatted code is a window into your soul, and we want people to be impressed with our order, attention to detail, and clarity of thought. When people look at code and see a jumbled block of code that doesn’t start or end clearly, it hurts our reputation.
If you think that code is “usable” is the first priority for professional programmers, you’re not going to fare very well. Your functionality today will most likely change in the next release, but the readability of your code will not.
When the original code has changed beyond recognition, the style and readability of the code will affect the maintainability of the code.
In the future, you’ll be remembered for your code style and discipline, not for a piece of code. Therefore, you need to format your code so that it is governed by simple rules that all team members can understand.
Write your “try-catch-finally” statement first
Georges Canguilhem explicitly states:
All men are liable to err, but it is the devil who persists in his error.
To err is human, to persist in error is diabolical.
Error handling is something every programmer has to do. Input can be abnormal, and devices can fail. As developers, we want the program to perform as we expect. However, the problem is not handling errors, but a clear and readable way of handling errors.
Much of the code is error-oriented, causing the main code logic to drown in it. This is completely wrong. Code should be clean, robust, and handle errors in an elegant way, which is also a mark of a good engineer.
One error-handling method is to catch all errors with an appropriate try-catch block. Whenever an exception occurs in the try part of the try-catch-finally, the catch part is executed.
Therefore, using try-catch-finally in your code may be a good choice. It helps you define the code you want to execute in the try section without worrying about what happens when the code goes wrong.
Every exception you throw should have a full context to determine the source and location of the error. Creative error messages are remembered long after the code was written, and even long after the author has left.
Bringing it all together
So how do you combine the techniques mentioned above?
The answer is code awareness, common sense in software engineering.
The answer is code-sense; the software equivalent of common sense.
According to Robert Martin, “Writing clean code requires a painful process of acquiring small skills called code awareness.” Some people are born with this feeling, while others acquire it through practice, persistence and perseverance. This awareness not only helps us distinguish good code from bad code, but also gives our code the ability to turn bad code into good code.
Code awareness helps developers choose the best tools to guide them to create more valuable, clean and beautiful code.
In short, having code awareness realizes that programmers are like painters who can turn a blank screen into a beautiful work of art that will be remembered for a long time.
As Harold Abelson put it:
Code is written first for people to read and then for machines to do.
References
“A Handbook of Agile Software Craftsmanship” — Robert Martin.
“A Handbook of Agile Estimation” — Mike Cohn
The original address
Medium.com/swlh/excell…
The translator reviews
The author uses aggressive language to tell people to pay attention to code readability, but everyone has similar ideas about naming, formatting, commenting, and error handling. Hopefully this somewhat radical article will help some students reduce the number of times others use WTF when reviewing your code.