The ten commandments of development

I wrote these a long time ago for an internal project that was ramping up.  Now I’ve been placed on a new project and have revisited these once more.  I think they’re pretty good, considering I originally wrote them two years ago.  Number ten is the only new one of the list.  Enjoy.

  • Thou shalt always follow the Framework Design Guidelines in thine namings
    • Any sketchy names should be used to mock the namer relentlessly
  • Thou shall not wrap thy code in try/catch blocks unless absolutely necessary
    • Less debug code during development means less code thrown away as the design changes
    • Trust your debugger and your call stack during pre-release development
    • When you must catch for debugging, wrap and rethrow, preferably with a custom exception
    • Exception handling should be performed at the last responsible moment, not indiscriminately!
  • Thou shall not spill thine logging code indiscriminately
    • Logging without planning leads to lousy logging code
    • It might be possible we use a type of “event sourcing” to publish changes in application state which can be consumed by both the UI and a logger by leveraging domain events via Rx
    • Wait and find out where you actually need logging, rather than where you *think* you need it
    • Don’t use logs to help test your design; look into adding tracing wrapped in preprocessor directives for this purpose
  • Thine code shall be well documented, within and without
    • XML Comments shall be placed on all methods and properties, private, protected, internal and public
    • Regular comments shall be placed on all fields and all tricky algorithms
  • Thine types shall be sealed, unless thou planneth for extension
    • Not thinking of inheritance when designing your types is an abomination
  • Thou shalt encapsulate thy Arguments, Returns and Exceptions when thy method is complex
    • Rather than have an ever expanding number of Arguments, wrap arguments in a new type
    • Avoid out Arguments by returning a new type that encapsulates the result of the method
    • Create a custom Exception type which holds more information about the method call
    • Is a method complex or trivial? If you don’t know, its trivial.
  • Thou shalt not worship One Object To Encapsulate Them All
    • If an object representing a domain of functions gets too large, split the domain into logical parts
    • Composition over inheritance should always be your guide in these matters
  • Thou shalt always strive to keep it simple, stupid
    • Simplicity = maintainability
    • For example, forego massive, obscure and complex ORMs for Micro ORMs
  • Thou shalt write at least one Unit Test for every public method of thine classes
    • This should test the primary (most important) assertion of the method (i.e., its most important function)
    • Your documentation should say what your method does, your tests should validate these statements
  • Thou shalt write thy API asynchronous and asynchronous shall thine API be
    • You should be asynchronous by default, and only synchronous when it is determined that they should be.

2 Responses to The ten commandments of development

  1. Terrance says:

    Well 100% code coverage for all public methods isn’t impossible but I’d question if it is really needed. I’d add test judiciously in locations likely to cause problems. I’d wager that most of the same places that are likely to cause problems in production are the places that caused problems in implementation.

    Also, Dude gotta see you guys at State Street. When are you gonna be around?

  2. noontz says:

    I´ll engrave this on the wall in front of me..
    In the mean time just wanna say your post on this thread
    saved my #### big time.. Thanks..

Comments are closed.