C # developer code review list

This is a general code review list prepared for C # developers and can be used as a reference during the development process. This is to ensure that most of the general coding guidelines can be noted during the coding process. For beginners and developers who lack experience (0 to 3 years of work experience), refer to this configuration code.

 

List

1. Make sure there are no warnings ).

2. It would be better to execute Code Analysis (enable all Microsoft Rules) and then eliminate all warnings.

3. Remove all useless usings. Removing unnecessary code during coding is a good habit. (Reference: msdn)

4. Check whether the object is 'null' in a reasonable place to avoid null Reference Exception during running.

5. Always follow the naming rules. Generally, the variable parameter uses the camper method, and the method name and class name use the Pascal method. (Reference: msdn)

6. Make sure that you understand the SOLID principle.

According to Wikipedia: in the field of programming, SOLID (single function, open/closed principle, Lishi replacement, interface isolation, and dependency inversion) it is the abbreviation of a memory technique introduced by Robert C. Martin in the early 21st century. It refers to the five basic principles of object-oriented programming and object-oriented design. When these principles are applied together, they make it more likely for a programmer to develop a system that is easy to maintain and expand software. SOLID includes the principle of cleaning the odor of the software code by triggering programmers to refactor the code of the software source code, so that the software can be clearly readable and can be applied when it is scalable. SOLID is a typical application in test-driven development and is an important part of the basic principles of agile development and adaptive software development. Reference: wiki/SOLID _ (Object-Oriented Design)

7. code reusability: if a piece of code has been used more than once, or you want to use it in the future, extract it into a method. Put repetitive work into common methods in related classes so that you can use them once you finish them. Develop common functions into user controls so that they can be reused across projects. (Reference: ①, ②)

8. Code consistency: for example, if Int32 is written as int and String is written as string, the unified form should be maintained in the code. It cannot be converted into an int and an Int32.

9. code readability: the code should be maintainable for other developers to understand. (Reference: msdn)

10. Release unmanaged resources, such as file I/O and network resources. Release them once they are used. You can use usings to include unmanaged code if you want to release objects automatically when they are out of scope. Reference: msdn

11. reasonably implement Exception Handling (try/catch and finally blocks) and exception records. Reference: msdn

12. Make sure that there are no more than 30 to 40 rows in the code.

13. Use the code management tool check-in/check-out code in a timely manner. (For example, TFS) refer to: codeproject.com

14. Mutual Review code: Exchange Code with your colleagues for internal review.

15. unit test: Write development test cases to complete unit test. Ensure that the basic test is completed before the code is delivered to QA. Reference: msdn

16. Avoid loop nesting for/foreach and nested if conditions as much as possible.

17. If the code is used only once, use the anonymous type. Reference: msdn

18. Use the LINQ query and Lambda expressions whenever possible to increase readability. Reference: msdn

19. reasonably use the var, object, and dynamic keywords. Many developers may feel confused or seldom know the similarities, so they should be avoided in exchange. Refer to: blogs. msdn

20. Use the access qualifier (private, public, protected, internal, protected internal) to limit the required range of each method, class, or variable. For example, if a class is only used in the Assembly, it is enough to define it as internal. Reference: msdn

21. Use interfaces where decoupling is needed. Some design patterns are also caused by the use of interfaces. Reference: msdn

22. Define the class as sealed, static, or abstract based on usage and needs. Reference: msdn

23. If you need to connect multiple times, use Stringbuilder instead of string, which can save heap memory.

24. check whether there is any code that cannot be executed. If so, modify the code.

25. comment before each method to describe its usage, input type, and return value type information.

26. Use a tool similar to Silverlight Spy to check and manipulate the XMAL rendering of the Silverlight application at runtime to improve efficiency. This can save a lot of time for returning and modifying back and forth when designing and executing the XAML.

27. Use filddler to track the performance of web applications and services by checking HTTP/network traffic and bandwidth.

28. If you want to confirm that Visual Studio is external, use the wcftestclient.exe tool or load the process to Visual Studio for debugging.

29. Use constants and readonly in any reasonable place. Reference:/msdn, msdn

30. Avoid forced conversion and type conversion whenever possible, because it may cause performance loss. Reference: msdn

31. For the class you want to provide custom information, please reload ToString (from the Object class ). Reference: msdn

32. Avoid pressing ctrl + c/ctrl + v directly from other codes. It is always recommended that you try it by hand, even if you have found the relevant code. In this way, you can train yourself to write code and understand the usage of that code correctly. In the end, you will never forget the code.

33. Keep good habits of reading books and articles and follow the practical guidance of the great gods. (For example, Microsoft experts and some famous experts, Martin Fowler, Kent Beck, Jeffrey Ritcher, Ward cunnheim, Scott Hanselman, Scott Guthrie, Donald E Knuth .)

34. Check whether the Code has memory leakage. If yes, make sure it has been corrected. Reference: blogs.msdn.com

35. participate as much as possible in technical seminars organized by experts to access the latest software trends, technologies and best practices

36. fully understand the concept of OOP and implement it in the Code as much as possible.

37. Understand the project design architecture and understand the program execution process as a whole.

38. Take necessary measures to prevent any cross-script attacks, SQL injection, and other security vulnerabilities.

39. always remember to encrypt the confidential and sensitive information (by using a good encryption algorithm), such as the password saved to the database and stored on the web. to avoid being manipulated by non-Authenticated Users.

40. Avoid using default keywords for known types (original types), such as int, decimal, and bool. In most cases, if you are not sure whether it is a value type or a reference type, use the generic type (T ). Reference: msdn

41. microsoft (in code analysis regulations and guidance) does not recommend the use of 'out' and 'ref '. These keywords are passed by reference. Please note that, the 'ref 'parameter should be initialized before being passed in to the called method, but the 'out' parameter is not like this. Reference: msdn

Translated by Hameed

Http://blog.jobbole.com/46255/.