[Advanced practice] -- Improving C # program quality (9)

140. Use the default access modifier.

If no access modifier is added, the member variables are private by default, and the class is internal by default. To clarify the access permissions, we recommend that you add access modifiers, which saves a lot of code. 141. If you do not know whether to add brackets, add them.

Braces consume two more lines of code. It is a debate that you do not need to increase the brackets for the code of a single statement. But to avoid introducing unnecessary bugs, add them. 142, always provide meaningful names.

We do not want to see the name of itemp. The name similar to I should only appear in the loop. The variable name should try to express what it should mean, rather than naming it randomly, which makes code maintenance difficult. If you don't want to maintain bad code, start with yourself. 143. The method abstraction level should be at the same level.

For example, void localinit () {remoteinit ();} void remoteinit () {}, localinit and remoteinit should be at the same level, and there should be no call relationship. You can make the following improvements: void Init () {localinit (); remoteinit () ;}. now their layers are the same. 144. One method only does one thing.

This usually determines whether a method has done too many things based on the method name. If yes, split the method into two methods. 145. Avoid excessive methods and classes.

The length of a method has previously been raised to be controlled in 50 or even shorter 30 rows. There is no hard requirement. The principle is that it should be suitable for reading, generally, it is better to have a screen that does not exceed the display. The length of the class should be less than 300 rows. If it is too large, you can consider refactoring. 146. Only necessary operations are made public.

Do not set all methods to public, which increases the difficulty of filtering methods and does not recommend exposing unnecessary members, setting a member to private is a good habit. Although it is private by default. 147. refactor multiple related attributes into a class.

This step is not implemented as soon as possible, but when refactoring finds that there are more than three relevant attributes, you can consider extracting them. 148, no repeated code.

Repetitive Code brings workload and risks to maintenance, and changes one place, while the other one is not modified. This problem can be solved by eliminating duplicates. 149. Use the table driver method to avoid too long if and switch branches.

For example, index-based table driver, string [] chineseweek = new string [] {"Monday", "Tuesday", "Wednesday", "Thursday", "Friday ", "Saturday", "Sunday"}; return chineseweek [(INT) W]; 150, using the anonymous method, Lambda expression instead of the method.

A small function body, such as about 3 rows, can be simplified using a Lambda expression. More than 3 rows can be extracted as a separate method, which is more conducive to reading. 151. Use the event accessors to replace the public event member variables.

Public event columnclickeventhandler columnclick {Add {This. events. addhandler (this, value);} remove {This. events. removehandler (this, value) ;}}, the above Code is more flexible than public event columnclickeventhandler columnclick; you can add additional logic in add and remove. Without additional logic control, the implementation is redundant and the latter can be used in most cases. 152, minimum. It is best not to write comments.

Comments are redundant when all the names can express the code intent. If you do not have enough skill, you are advised to add comments in a proper amount. People who need to refactor your code must understand the code you have written. 153. Comments should be given if the code throws an exception.

The annotation should be XML, and the user can see the generated help document to know what exceptions to handle. 154. Do not over-design. Experience the fun of restructuring in agility. 155. The test code should be submitted along with the production code.

It is necessary to write a single test code. Only when the Code test passes can we reconstruct it with confidence. Without it, as code maintenance continues, more and more bugs will be introduced. 156. Use features to provide different versions for the application.

For example, our programs may be divided into the trial version and the full version. They can use different functions. We cannot create two different programs separately and use the attribute) to complete this customization. Use the [conditional ("online")] feature for methods or classes, and define # define online at the top of the file. Conditional can be plural, that is, you can indicate that a method is online and offline at the same time. We can also define online and offline in project properties to make them valid for the entire project. 157. Automated Testing starts from the first interface.

This focuses on automated testing of the UI. Code UI automation is a UI automation test tool provided by vs. You should learn it when appropriate.

[Advanced practice] -- Improving C # program quality (9)