This is a creation in Article, where the information may have evolved or changed.
The author of this article: Bole online-yemengying. No reprint without the permission of the author!
Welcome to Bó Lè Online columnist.
Objective
I decided to translate a person's article O (∩_∩) o~ because of my recent exhaustion of inspiration. As a always want to learn go, but think for a long time not to get started, I picked the article to write go, by the way to help myself familiar with go. The original is Dave Cheney according to his own Golanguk speech, the full text of the solid principle as the line, tell what kind of Go code is good code, of course, the SOLID principle also applies to other languages.
The English text is rather long and is translated by me and Kevin.
How many Go language developers are there in the world?
How many Go developers in the world do you pinch? Think of a number in your mind and we'll go back to that topic at the end.
Code Review
How many people use code review as part of their job? [The people who listened to the speech raised their hands]. Why do you want to do code review? [Some people answer in order to stop the bad code]
If code review is in order to catch bad codes, then the question is, how do you tell if the code you're review is good or bad?
We can easily say "This code is Hot Eyes" or "the source is too hanging", like saying "This picture is Beautiful", "This House is really atmosphere" the same. But these are all subjective, and I want to find some objective ways to measure whether the code is good or not.
Bad code
Let's take a look at the code review, which features a piece of coding that is considered bad code.
- Rigid code is not very stiff? Whether the cost of modifying the code increases due to strict types and parameters
- Is fragile code fragile? Is it a small change that can cause great damage?
- Is immobile code hard to refactor?
- Is the Complex code overly designed?
- Verbose When you read this code, can you clearly know what it does?