Java code specifications

I have been in the company for more than a month. Because I just got out of the project, the department manager asked me to take a break and wait for the next project to be finalized. I did not expect that my stay was more than a month. This kind of feeling of not working really made me feel at a loss. The department manager saw it and asked me to help him with OA and improve and add some functions. When I got the company's OA code, the environment started after it was set up. When I opened several files, I saw a line of messy code flying in front of me, and the logic was not clear at all, suddenly, my head was too big. God, this made me start from where, so I had a deeper understanding of how well code is written.
I think the first principle of code standards is to let people who read your code see the context at a glance, rather than a bunch of variables. if... else... layer-by-layer nesting like spider web makes it take half a day for the person who takes over your code to send a sigh of "oh, it was like this. Let's imagine, if someone makes such a sigh, then what will he say? haha, he will say, "How can this person write such junk code, nima ". Of course, this situation is not our original intention, nor the evaluation we want. Therefore, we must write the code from the perspective of others and standardize it so that everyone who takes over can easily understand it and change it to get started quickly. The following are some of the key points I will consider when writing code by myself. I hope to discuss them with you:
1. annotation (concise comment, comment location, comment quantity)
The content of the comment must be simple, clear, and accurate, so as to prevent the ambiguity of the comment. Incorrect comments are not helpful but harmful. In addition, ensure that the annotation is adjacent to the code described by it, that is, the proximity principle of the annotation.
Someone may ask, isn't too many comments invisible to make our code file very large? In fact, annotations are ignored during code compilation and are not compiled into the final executable file. Therefore, Annotations do not increase the size of the executable file.
Every method I write is in the following format:
/**
* Function description .....
* @ Param parameter description...
* @ Return description ....
*/
Public void xxx (String xxx ,....){
......
}
2. Name (in English)
Most languages only support letter programming. Some programming languages can use Chinese as variable names! Like PHP, but adopting Chinese is a very unscientific practice. because it involves character sets, cross-platform platforms, and many other issues, we should never use it.
Can pinyin be used? I don't think it is desirable, because the abbreviation of Pinyin is too elegant. For example, if you think of a "SB", you only think of it as "silly X ", instead, we will not think of "go to work", "by the way", "casually", etc. If we use "Shab" or "Sbi" as shorthand, it will be more incredible, chinese pinyin cannot be abbreviated, So I advocate English, because English does not produce ambiguity when abbreviated, unless you make it possible to produce ambiguity.
3. if... esle... (use else as little as possible to avoid nesting)
If... else... is a logical control statement required by any programming language, that is, the branch structure. However, when using it, we should pay attention to the principle of easy-to-read, and should not be nested layers (not as a last resort.
Summary: in fact, there are still many points to note when writing code. I only wrote the three most important aspects I usually pay attention to. I hope to share with you some suggestions. If not, please kindly advise. I still have a lot to learn, and there is still a long way to go. Well, IT's not too early. IT's time to take a rest. The body is the capital of the revolution. We IT people should also remember to stay healthy and never stay up late.

This article is from the "Internet navigator" blog