The 41 recommendations of the C # Developer review code--Go

Turn from: Connect http://www.cnblogs.com/smiler/p/3274512.html

1. Make sure there are no warnings (warnings).

2. It would be better if you performed Codeanalysis (all Microsoft Rulesenabled) before removing all warnings.

3. Remove any unused usings. It's a good habit to get rid of extra code during coding. (Reference: MSDN)

4. Check if the object is ' null ' in a reasonable place and avoid null Reference Exceptionwhen running.

5. Always follow the naming convention. In general, variable parameters use the Hump naming method, the method name and the class name using the Pascal nomenclature. (Reference: MSDN)

6. Make sure you understand the solid principles.

According to Wikipedia definition: In the field of programming,SOLID ( single function, open/close principle, Richter replacement, interface isolation and dependency reversal ) is by Robert C. Martin introduced the acronym for Memory in the early 21st century, referring to the five basic principles of object-oriented programming and object-oriented design. When these principles are applied together, they make it more possible for a programmer to develop a system that is easy for software maintenance and expansion. Solid contains the principle of software code odor sweeping by triggering code refactoring of the software source code , which enables the software to be clearly readable and can be applied when extensible. Solid is typically used in test-driven development and is an important part of agile development and the basic principles of adaptive software development. Reference: Wiki/solid_ (object oriented design)

7. Code reusability: If a piece of code has been used more than once, or if you want to use it in the future, extract it as a method. Put the repetitive work into a common approach in the relevant classes so that once you're done someone else can use it. Develop common functionality into user controls so that they can be reused across projects. (Reference: ①, ②)

8. Code consistency: For example, Int32 writes int,string as a string and should remain in uniform form in the code. I can't write an int for a while and write Int32.

9. Code readability: The code should be maintainable and easy for other developers to understand. (Reference: MSDN)

10. Release unmanaged resources, such as file I/O, network resources, and so on. They should be released once the use is finished. You can use Usings to enclose unmanaged code if you want to automatically dispose of the object once it is out of range. Reference: MSDN

11. Reasonably implement exception handling (Try/catch and finally blocks) and exception logging. Reference: MSDN

12. Make sure that the number of methods in the code is not too many, not more than 30 to 40 lines.

13. Check-in/check-out Code with Code management tools in a timely manner. (e.g. TFS) Reference: CodeProject.com

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

15. Unit Testing: Write a development test case to complete unit tests to ensure that the code is delivered to QA before the basic test is complete. Reference: MSDN

16. Avoid For/foreach loop nesting and if condition nesting as much as possible.

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

18. Use LINQ queries and lambda expressions as much as possible to increase readability. Reference: MSDN

19. Use the Var, object, and dynamic keywords appropriately. Because a lot of developers will be confused or know little, will feel they are somewhat similar, so exchange use, this is to avoid. Reference: BLOGS.MSDN

20. Use the Access qualifier (private, public, protected, internal, protected internal) to qualify the scope of each method, class, or variable. For example, if a class is only used within an assembly, then defining it as internal is sufficient. Reference: MSDN

21. Use the interface where it is necessary to remain decoupled, and some design patterns appear due to the use of the interface. Reference: MSDN

22. Define the class as sealed, static, or abstract according to usage and needs. Reference: MSDN

23. If multiple concatenation is required, use StringBuilder instead of string, which can save heap memory.

24. Check if there is an impossibility to execute the code, if any, please modify.

25. Comment before each method, stating its usage, input type, and return value type information.

26. Use a Silverlight spy-like tool to improve efficiency by checking and manipulating the xmal rendering of Silverlight apps at runtime. This can save a significant amount of time to return and back-and-forth modifications when designing a XAML execution.

27. Use the Filddler tool to track the performance of Web apps and services by examining http/network traffic and bandwidth.

28. If you want to confirm a method other than Visual Studio, use the WCFTestClient.exe tool, or load its process into Visual Studio to debug.

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

30. Avoid casting and type conversions as much as possible, as they can cause performance penalty. Reference: MSDN

31. For classes that you want to provide custom information, overload ToString (from the object class). Reference: MSDN

32. Avoid ctrl+c/ctrl+v directly from other code. Always advise yourself to knock with your hand even if you have found the relevant code. This can exercise your ability to write code, but also to understand the use of the code correctly. Eventually you will never forget that code.

33. Maintain good habits of reading books and articles, and follow the practice guidance of the Great gods. (such as Microsoft experts and some famous experts, Martin Fowler, Kent Beck, Jeffrey ritcher, Ward Cunningham, Scott Hanselman, Scott Guthrie, Donald E Knuth .）

34. Verify that the code has a memory leak. If so, make sure that it has been corrected. Reference: blogs.msdn.com

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

36. Get a thorough understanding of the OOP concept and implement it as much as possible in your code.

37. Know the project design structure, can understand the process of the procedure in the whole.

38. Take the necessary steps to prevent any cross-scripting attacks, SQL injections, and other security vulnerabilities from being avoided.

39. Always remember to encrypt confidential and sensitive information (by using a good encryption algorithm), such as a password saved to a database and a connection character saved in the Web. config file, to avoid being manipulated by non-authenticated users.

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

41. Microsoft (in the Code Analysis Regulations and guidelines) does not recommend the use of ' out ' and ' ref ', which are referenced by reference, note that the ' ref ' parameter should be initialized in the calling method before passing in the called method, but the ' out ' parameter is not. Reference: MSDN

The 41 recommendations of the C # Developer review code--Go