C# Programming Guidelines（摘录）

C# Programming Guidelines（摘录）

以下条目来自于Larry O'Brien与Bruce Eckel的《Think C#》一书，我个人认为英文表达胜于使用中文来表达，所以也没有翻译相关的内容。

 

1. Elegance Always pays off.

2. First make it work, then make it fast.  在敏捷开发中，有一条原则：Keep it simple

3. Remember the "divide and conquer" principle.

4. Separate the class creator from the class user (client programmer)

5. When you create a class, attempt to make your names so clear that comments are unnecessary.

6. Your analysis and design must produce, at minimum, the classes in your system, their public interfaces, and their relationships to other classes, especially base classes.

7. Automate everything. 类似于敏捷开发中的Continue Integrated.

8. Write the test code first (before you write the class) in order to verify that your class design is complete. 类似于敏捷开发中的Write Test First

9. All software design problems can be simplified by introducing an extra level of conceptual indirection.

10. An indirection should have a meaning.

11. Make classes as atomic as possible.  单一职责原则(SRP)很好地解释了这一点，SRP可以理解为为“就一个类而言，应该仅有一个引起它变化的原因”，详细信息请参阅《Agile Software Development Principles, Patterns, and Practices》；

12. Watch for long argument lists. 可以使用重构中的Introduce Parameter object（引入参数对象）来重构代码，关于重构，请参阅《Refactoring: Improving the Design of Existing Code》

13. Don't repeat yourself. 不要使你的代码有Duplicated Code坏味道，当有后可以使用重构中的Extract Method手段来重构代码；

14. Watch for switch statements or chained if-else clauses. 不要使你的代码有Switch Statements坏味道，当有后可以使用重构中的Replace Conditional with Polymorphism手段来重构代码；

15. From a design standpoint, look for and separate things that change from thins that stay the same.

16. Don't extend fundamental functionality by subclassing.

17. Less is more.

18. Read your classes aloud to make sure they're logical.

19. When deciding between inheritance and composition, ask if you need to upcast to the base type.

20. Use data members for variation in value and method overriding for variation in behavior.

21. Watch for overloading.

22. Use exception hierarchies;

23. Sometimes simple aggregation does the job.

24. Consider the perspective of the client programmer and the person maintaining the code;

25. Watch out for "giant object syndrome."

26. If you must do something ugly, at least localize the ugliness inside a class.

27. If you must do something nonportable, make an abstraction for that service and localize it within a class.

28. Objects should not simple hold some data.

29. Choose composition first when creating new classes from existing classes;

30. Use inheritance and method overriding to express differences in behavior, and fields to express variations in state.

31. Watch out for variance;

32. Watch out for limitation during inheritance.

33. Using design patterns to eliminate "naked functionality.";

34. Watch out for "analysis paralysis.";

35. When you think you've got a good analysis, design, or implementation, do a walkthrough.

 

Implementation

36. In general, follow the Microsoft coding conventions.

37. Whatever coding style you use, it really does make a difference if your team (and even better, your company) standardizes on it.

38. Follow standard capitalization rules.

39. Don't create your own "decorated" private data member names;

40. Follow a "canonical form" when creating a class for general-purpose use.

41. Sometimes you need to inherit in order to access protected members of the base class.

42. If two classes are associated with each other in some functional way (such as containers and iterators), try to make one an inner class of the other;

43. Anytime you notice classes that appear to have high coupling with each other, consider the coding and maintenance improvements you might get by using inner classes;

44. Don't fall prey to premature optimization;

45. Keep scopes as small as possible so the visibility and lifetime of your objects are as small as possible.

46. Use the containers in the .NET Framework SDK.

47. For a program to be robust, each component must be robust.

48. Prefer compile-time errors to run-time errors 尽可能地将错误在编译阶段解决;

49. Watch for long method definitions;

50. Keep things as "private as possible"; 应尽量少暴露外部接口给用户

51. Use comments liberally, and use the comment-documentation syntax product your program documentation.

52. Avoid using "magic numbers"; 应该使用常量来代替

53. When creating constructors, consider exceptions.

54. If your class requires any cleanup when the client programmer is finished with the object, make your class implement IDisposable interface;

55. When you are creating a fixed-size container of objects, transfer them to an array;

56. Choose interfaces over abstract classes;

57. Inside constructors, do only what is necessary to set the object into the proper state;

58. Watch out for accidental overloading;

59. Watch out for premature optimization;

60. Remember that code is read much more than it is written;