TABLE OF CONTENTS

Class Design

1. Provide consistent and intuitive class interface. 5

2. Provide common properties of classes in a base class. 9
3. Do not expose implementation details in the public interface of the class. 12
4. Consider providing helper classes while designing large classes. 14
5. Keep the data members private. 18
6. Provide lowest possible access to methods. 23
7. Strive for loose coupling between classes. 26
8. Beware of order of initialization problems. 29
9. Write unit tests for classes. 31
10. Avoid low-level code. 34

Object Creation and Handling

11. Avoid calling virtual functions in constructors. 37

12. Consider providing factory methods. 43
13. Make constructor private if there are only static members in the class. 45
14. Avoid creating unnecessary temporary objects. 47
15. Prefer creating immutable objects. 52
16. Consider creating and using null objects. 54
17. Provide special objects with read only access in the class itself. 56

Overloading

18. Overload operators only if it is natural and improves readability of code. 60

19. Overload symmetrical operators or family of operators. 63
20. Overload functions only if it is intuitive and unambiguous to users. 65
21. Overload functions only if the functions do semantically the same thing. 69

Inheritance
22. Do not use inheritance when structure and behaviour are same for related classes. 72
23. Prefer object composition over inheritance. 74
24. Avoid inheriting from multiple classes. 76
25. Prohibit inheriting from a standalone class if the class is not meant for inheritance. 80
26. Consider making concrete leaf classes non-inheritable. 84
27. Write code referring to generic interfaces of classes. 86
28. Beware of versioning problems in evolving base classes. 90
29. Avoid deep inheritance hierarchies. 94

Abstract Classes and Interfaces

30. Consider making common base classes as abstract classes. 96

31. Use abstract classes for modelling abstract properties and sub-classing. 98
32. Provide default implementation class(es) with abstract or pure interface classes. 100
33. Use pure interface classes for sub-typing and multiple inheritance. 103
34. Consider providing adaptor classes for pure interface classes. 106
35. Keep in mind that pure interface classes are difficult to evolve. 109

Runtime Polymorphism

36. Use virtual functions instead of chained if-else or switch statements. 112
37. Follow Liskov’s Substitution Principle (LSP). 115
38. While overriding, preserve the basic properties of methods. 117

Reflection and RTTI

39. Avoid using reflection extensively. 121

40. Prefer using higher-level language features instead of reflection. 127
41. Avoid using RTTI extensively. 131
42. Prefer virtual functions to RTTI. 133

Exception Handling

43. Write robust code to avoid raising unnecessary exceptions. 136

44. Throw user-defined exceptions for application/logical errors. 140
45. Think about providing graceful exit if you cannot handle an exceptional condition. 142
46. Never write empty (do nothing) catch blocks. 145
47. Clearly document the exceptions that a method might throw. 147
48. Avoid throwing or catching generic exceptions; prefer specific exceptions. 149
49. Provide catch handlers for specific exceptions before general exceptions. 151
50. Provide contextual information while throwing an exception. 157

Namespaces

51. Use namespaces for avoiding name-clashes and organizing the software. 158
52. Avoid hiding of names in different scopes. 160
53. Selectively expose the types to the clients. 164
54. Hierarchically partition the namespace. 166
55. Selectively introduce only the specific namespace members you need to the code. 169

Design and Reuse

56. Strive for eliminating all forms of code duplication. 173

57. Use design patterns whenever appropriate. 175
58. Provide frameworks for effective reuse of architectural design. 177
59. Provide class libraries for any set of related reusable classes. 179
60. Know and make best use of the standard library. 182