fork download 
  1. Programming Rules
  2. -----------------
  3. duplication is #1 rookie mistake, modularity is key
  4. avoid setters, favor immutible value types
  5. define operations instead of setters. e.g: favor rect.resize(w, h) over setWidth and setHeight.
  6. class interfaces should be minimal and complete
  7. use free functions for additional functionality. e.g. `unsigned area(rect)` is better than `rect.area()`
  8. minimal scope 
  9. avoid C arrays
  10. if you must use a C array, put it in a struct so that you can use value initialization and normal copy semantics.
  11. always prefer natural semantics. e.g. a == b is better than `memcmp(&a, &b, sizeof(a))`
  12. favor unsigned integers.
  13. constructor fully initializes an object (avoid configuration with setters)
  14. favor exceptions over assertions or error codes
  15. the thrower of an exception should not worry about the catching of it.
  16. define catch blocks from the top down (nested safety nets)
  17. favor declarative programming
  18. favor lazy evaluation
  19. less code means less bugs
  20. primarily aim for a minimal and correct solution
  21. use test-driven design.
  22. use tracer bullets.
  23.  
  24. compile at a high warning level, treat warnings as errors
  25. avoid deep scope nesting
  26. avoid else branches
  27. (?) production code might require a more explicit naming style
  28. (?) production code might benefit from a more conserative design (less nifty)
  29. duplication reveals bad design
  30. the law-of-demeter is not overkill
  31. most application-level classes should use pimpl
  32. law-of-demeter goes hand in hand with pimpl
  33. a little duplication is ok
  34.  
  35. design != categorization
  36. use a top-level namespace
  37. you may define second-level namespaces to mark boundaries betweeen broad areas like ui, networking, rpc,  …
  38. however, resist the temptation to create more sub-categories. there is no added value and it's cumbersome to maintain.
  39.  
  40. categorization is the #2 rookie mistake
  41. top down hierarchical thinking is the root problem, not inheritance
  42. bottom up multiple-inheritance is a technique for composition
  43. you need to identify common and the specific parts. recognize what is orthogonal.
  44. dynamic polymorphism is not inferior to static polymorphism
  45. macros are not evil if you use them responsibly
  46. function overloading is elegant way to implement static polymorphism
  47. use template argument deduction if possible
  48. (?) favor overloading with identity<T> over specializing a function for T
  49.  
  50. template specialization should usually be avoided for classes that are part of the public API
  51. template specialization is most commonly used on traits, policies and small helper classes
  52.  
  53.  
  54. pass argument by reference, store as pointer
  55. passing a pointer argument tells the user that the pointer may be null and must be checked before dereferencing.
  56.  
  57. good design is a compromise between (in order of importance)
  58.  (1) inherent code quality (modularity, orthogonality, etc…)
  59.  (2) human readability
  60.  (3) tool readability
Not running #stdin #stdout 0s 0KB
comments (?)
stdin 
Standard input is empty
stdout 
Standard output is empty
https://ideone.com/I8imQX
language:
Text (text 6.10)
created:
11 years ago
visibility:
public

Share or Embed source code

Discover > Sphere Engine API

The brand new service which powers Ideone!

Discover > IDE Widget

Widget for compiling and running the source code in a web browser!