Razie's Guidelines for healthy code

Along the decades of programming, design, architecture, review and mentoring, I settled on some underlying principles or guidelines, which form the basis of any successful programming enterprise.

For those that I can bring up, from the sub-conscious to the foreground, I will try my hands at a short description below.

Here's a brief list. It will change in time, as relative priorities shift and I identify others/forget these:

  • Pattern recognition
    • The basic principle of programming: Commonality and variability analysis
    • | Similarity and Uniformity
    • [#code_patterns] Patterns: architectural, design or structure
  • Multi-paradigm toolbox
  • Allocate responsibilities properly
  • KISS or simplify until there's nothing left to remove
  • Think upfront
  • play
  • Behavioral
    • 7 of 7

Here's a bunch of related blogs:

Pattern recognition

TODO

Similarity and Uniformity

One must strive to create and maintain as much similarity and uniformity as possible. This applies to system architecture, design, interfaces, related code snippets.

For example the CRUD pattern stands behind pretty much any DAO, yet if all DAOs call these methods different names, we'll waste a lot of time

In the code below, note the second method returns a tuple, although the second is Nothing:

  // from http://james-iry.blogspot.com/2007/11/monads-are-elephants-part-4.html
 object RTConsole_v1 {  
   def getString(state: WorldState)               = (state.nextState, Console.readLine)  
   def putString(state: WorldState, s: String) = (state.nextState, Console.print(s) )  
 }

The client code might be

   currState = rtc.getString(WorldState)               ._1
   currState = rtc.putString(WorldState, "hello")   ._1
 }

Yes, it is ok to sacrifice a few small things for generating similarity. Things like poltergeists (like above) or slightly more complicated client code ( s = x () ._1 ) instead of just ( s = x () ). In this specific case you could argue that the name of the second method implies not returning extra info and you'd be right as well…you will need to use your brain to figure out when relative priorities shift and enough becomes too much :)

Patterns: architectural, design, structure

Patterns are obviously important and their most prominent manifestation is design patterns. Some have advanced architectural patterns as well (is 3-layered systems a pattern?).

There aren't that many important patterns though. I would say that most should limit themselves to say 7 good patterns…I'll start my list here…what's yours?

  • Factory - chicken? …egg? …anyone?
  • DAO - duh!
  • Facade - the OO killer!
  • Proxy (adapter, bridge)
  • Locator - JNDI on steroids
  • Strategy

It is usually more important to avoid the anti-patterns…in fact, after reading both the patterns and the anti-patterns books, I re-read only the anti-patterns book :).

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License