What is good code-code neat way to read notes

According to the book I read, "code neat Way" in a sentence:
"The only effective standard for measuring code quality: wtf/min"

From a philosophical point of view, it must be said that this is really objective ...
I haven't had much of a definition of good code in the near future. It should be said that there is no definite definition. But when I see a good code and bad code, as a beginner I can also tell which is good and which is bad.
So objectively speaking. There is a difference between good code and bad code. Below I will briefly record some of the key points in this book, on the one hand to deepen their impressions. On the other hand, pass the boring time, quickly through the days without women's tickets. How to name

This is really important, big dare not say. As the two three books like us out of the programmer really do not pay attention to this point. Most of the friends around are because their English is not good, and lead to the naming of the word is not in line with the meaning. This will make the code more and more difficult to understand over time. Of course the direct impact is that the team's productivity is declining rapidly. The second chapter of the book refers to the point about naming the mentioned points about: Avoid using magic numbers to avoid misleading use of meaningless letters (such as a, B, I ...). Use the unanimously approved, universal naming of the team (such as: generatexxx build xxx, searchxxx search xxx, dosomethingwithxxx use XXX to do what operation ...) Avoid coding (avoid using variable prefixes, suffixes) class names should use nouns or noun phrases, avoid using verb method names to name each abstract concept with a verb or verb phrase, and consistent (the code in the team should not show a different name for the same abstract concept, For example the same means to get this abstract concept should not appear in the code to the same expression "get" the abstract concept of multiple named Fetch, retrieve, get, obtain, etc.) multi-use solution domain naming (examples to be perfected) The separation solution area is named after the name of the problem domain (the name of the problem domain should be used when you encounter code that is closer to the problem area involved)how functions are encapsulatedPackaging Fundamentals-Short(check if the function is short: see if the function can be divided into different steps) do only one thing
The difficulty is how to define the matter. After the difficult evolution is actually athingsWithStepsHow to divide the problem.
For example, there is now a question of how to put an elephant in the refrigerator. You can abstract a function called Putelephanttorefrigerator ().
Specifically, the internal implementation of this function can be divided into three steps:
Open the refrigerator openrefrigerator (). Push the elephant into the refrigerator pushelephantintorefrigerator (). Close the refrigerator ().
For the elephant into the refrigerator this thing, putelephanttorefrigerator () only do one thing. It's just a three-step process. But for Openrefrigerator () thisSteps, it is actually anotherthings。 It's just a step in the matter relative to Putelephanttorefrigerator (). SothingsAndStepsJust different at the level of abstraction.The same is true for functionsTry to keep each function at the lowest level of abstraction (the appearance of multiple hierarchical functions can lead to confusing code) the statements within the function are at the same level of abstraction. When you encounter a switch statement, you should consider replacing the switch's related statements with polymorphic (abstract Factory + policy-configurable polymorphism)