Detailed description of C# coding specifications

First of all, we need to understand a few points.
1. In addition to letting him run, there is also a very, very important function when writing codes is to maintain them. Because without unchanging codes, the code will inevitably change if it needs to change.
2. You are not writing code alone. There is a team behind you. Anyone in this team may change your code. If you write it in a non-standard manner, the people behind you will write it. For example, the original code might look like this.

But after a while, another requirement is needed. For "MU-WS", you also need to follow the above logic. How would you write it? If you just complete the task, you might write it like the following

If you really write this way, you will be the initiator. If the people behind you are the same as you, they will copy it to you. The final code may be like this.

Have you seen the effect? ​​You need to take off the long strip below to see the entire code. This is the fruit you get after planting your "cause". So we need to improve. A common improvement is carriage return and line breaks to ensure that all code is within the range you can see at a glance. The improved code is as follows:

Is it a little refreshing and better? If you write like this when you first modify the code, the person who comes to the next one will write like this. They may think that there should be no problem with the previous person writing like this. Although the code looks a bit awkward, we can look at this code with an appreciation point. If you think about it, there is a better way, why not switch?

Isn't it simpler? If you write this way, the people behind will not hesitate to add a case "" to the back: because this is a very familiar grammar, and there is no need to doubt the correctness of this writing method at all, so we can look at this code with an appreciation point of view.
3. We must admit that we have only so many minds and our heads are so big. We cannot see ten lines at a glance or express them in a straightforward manner, so don’t write codes that cannot tell what they mean in a word.
The above ideas are based on the pain, loss, frustration, all kinds of dissatisfaction and complaints of maintaining other people's code. Therefore, the code specifications need to be paid attention to at all times. Here we summarize some specifications and warn ourselves not to be the initiator.
1. Put only one class in a file, the class name is the same as the file name. Do not write several classes in a file, so you can see it clearly.
2. Do not write more than 1000 lines of code in a file, except for those larger entity classes. Actually, I would like to say that more than 500 lines may seem a bit tired, but in our system there are more than 10,000 lines of code.
3. The code of a method should not exceed 100 lines. In fact, I want to say that methods with more than 50 lines will look a bit tired. But there are many ways to get over 200 lines of code in our system.
5. Avoid writing methods with more than 5 parameters. If so, please use a class or structure to pass it.
6. A method has only one return result; , do not return the result multiple times, it is best to assign a value to the return result, and finally return result;
7. Don’t comment on very simple codes, as they will be noisy and misleading, because most of the time you write is one-sided.
8. Don’t record the logs everywhere when recording them. If possible, only one log is recorded for a customer (such as placing an order).
In addition, here are some improvements I have made to the code. Everyone is welcome to point out the shortcomings.
1. Use indentation when the parameters are too long

Use indentation when conditions are too long

3. Use ternary expressions

4. Use blue expressions

5. Use switch expressions, see above.
6. Use array to include

You can see that indentation is also used in the code.
Everyone is welcome to list the concise code you have encountered.