worthy of the name
Specify the object of measurement and the unit of measurement avoid mana
Avoid going against the intent Beware of using less distinct names Avoid container type names in names Avoid O01l
make meaningful distinctions
Name according to intention, pay attention to the distinction between opposites (src and obj) Avoid ambiguity, avoid the same meaning but different names Avoid crap redundancy (nameString\UserTable....are bad)
so that everyone can read
Mainly for the convenience of communication Avoid self-made words, use proper formal words Not to mention spelling
Use a searchable name
This depends on the project naming convention Try to be consistent with your predecessors Summarize naming rules for quick search More attention should be paid to resource files, constant classes, etc.
Avoid using encoding names
This ignore will not have this problem now
Avoiding mental mapping is the right way
class name/object name noun method name verb
Use solution realm name
Add meaningful context
For example, the State in the address appears alone and cannot know its clear meaning and can be named AddState But looking at our current code it doesn't do this very well
Of course don’t add useless context
In the final analysis, the most important thing is to make the name understandable. Everyone will have a similar or even the same name for this class or method, so that I don’t have to remember the specific name and have a set of naming logic to directly find the corresponding code.
What about short and concise focusing on a single function?
There is only one level of abstraction per function
Utilize polymorphism to ensure switch statements are buried in lower abstractions
Use descriptive names
function with as few parameters as possible
If there are three or more parameters, it means that the parameters are encapsulated into classes based on the need. Because some parameters themselves are combined into a set of concepts, such as coordinates x, y two parameters can use a Point class as input parameters.
Make sure the function has no side effects
Try to avoid using output parameters
Pull away tyy/catch
only one return loop don't have break / continue don't use goto
Without it, only skilled ears
In a word, delusional comments can beautify your code, so write the code honestly!
It’s better to let the code speak for itself, not comments
Of course, some comments are required, so you have to write them well
What is a good note
Legal information explain intent Explain obscure code (preferably written in plain language) Warning comment TODO Important code enlargement JavaDoC
Talking to oneself superfluous nonsense Misleading comments are often damaging redundancy