C++ coding standards : 101 rules, guidelines, and best practices /
Consistent, high-quality coding standards improve software quality, reduce time-to-market, promote teamwork, eliminate time wasted on inconsequential matters, and simplify maintenance. Now, two of the world's most respected C++ experts distill the rich collective experience of the global C++ co...
Clasificación: | Libro Electrónico |
---|---|
Autor principal: | |
Otros Autores: | |
Formato: | Electrónico eBook |
Idioma: | Inglés |
Publicado: |
Boston :
Addison-Wesley,
2004.
|
Colección: | C++ in-depth series.
|
Temas: | |
Acceso en línea: | Texto completo (Requiere registro previo con correo institucional) |
Tabla de Contenidos:
- Cover
- Contents
- Preface
- Organizational and Policy Issues
- 0. Dont sweat the small stuff. (Or: Know what not to standardize.)
- 1. Compile cleanly at high warning levels.
- 2. Use an automated build system.
- 3. Use a version control system.
- 4. Invest in code reviews.
- Design Style
- 5. Give one entity one cohesive responsibility.
- 6. Correctness, simplicity, and clarity come first.
- 7. Know when and how to code for scalability.
- 8. Dont optimize prematurely.
- 9. Dont pessimize prematurely.
- 10. Minimize global and shared data.
- 11. Hide information.
- 12. Know when and how to code for concurrency.
- 13. Ensure resources are owned by objects. Use explicit RAII and smart pointers.
- Coding Style
- 14. Prefer compile- and link-time errors to run-time errors.
- 15. Use const proactively.
- 16. Avoid macros.
- 17. Avoid magic numbers.
- 18. Declare variables as locally as possible.
- 19. Always initialize variables.
- 20. Avoid long functions. Avoid deep nesting.
- 21. Avoid initialization dependencies across compilation units.
- 22. Minimize definitional dependencies. Avoid cyclic dependencies.
- 23. Make header files self-sufficient.
- 24. Always write internal #include guards. Never write external #include guards.
- Functions and Operators
- 25. Take parameters appropriately by value, (smart) pointer, or reference.
- 26. Preserve natural semantics for overloaded operators.
- 27. Prefer the canonical forms of arithmetic and assignment operators.
- 28. Prefer the canonical form of ++ and
- Prefer calling the prefix forms.
- 29. Consider overloading to avoid implicit type conversions.
- 30. Avoid overloading & &, '', or, (comma)
- 31. Dont write code that depends on the order of evaluation of function arguments.
- Class Design and Inheritance
- 32. Be clear what kind of class youre writing.
- 33. Prefer minimal classes to monolithic classes.
- 34. Prefer composition to inheritance.
- 35. Avoid inheriting from classes that were not designed to be base classes.
- 36. Prefer providing abstract interfaces.
- 37. Public inheritance is substitutability. Inherit, not to reuse, but to be reused.
- 38. Practice safe overriding.
- 39. Consider making virtual functions nonpublic, and public functions nonvirtual.
- 40. Avoid providing implicit conversions.
- 41. Make data members private, except in behaviorless aggregates (C-style structs).
- 42. Dont give away your internals.
- 43. Pimpl judiciously.
- 44. Prefer writing nonmember nonfriend functions.
- 45. Always provide new and delete together.
- 46. If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow).
- Construction, Destruction, and Copying
- 47. Define and initialize member variables in the same order.
- 48. Prefer initialization to assignment in constructors.
- 49. Avoid calling virtual functions in constructors and destructors.
- 50. Make base class destructors public and virtual, or protected and nonvirtual.
- 51. Destructors, deallocation, and swap never fail.
- 52. Copy and destroy consistently.
- 53. Explicitly enable or disable copying.
- 54. Avoid slicing. Consider Clone instead of copying in base classes.
- 55. Prefer the canonical form of assignment.
- 56. Whenever it makes sense, provide a no-fail swap (and provide it correctly).
- Namespaces and Modules
- T$29.