programming concepts
In Outliving the Great Variable Shortage, Tim Ottinger invokes Curly’s Law: A variable should mean one thing, and one thing only. It should not mean one thing in one circumstance, and carry a different value from a different domain some other time. It should not mean two things at
code quality
Unless you’ve been living under a rock for the last few years, you’ve probably heard about the game Katamari Damacy. The gameplay consists of little more than rolling stuff up into an ever-increasing ball of stuff. That’s literally all you do. You start by rolling up small
clean code
Christopher Seiwald’s Seven Pillars of Pretty Code argues that code that looks good, works good: 1. Code changes should blend in with the original style. It should not be possible to discern previous changes to a file without seeing the previous revisions. Nothing obscures the essential visual cues more
programming practices
From an audio interview with Ron Jeffries: The reason the kitchen is a mess is not because the kitchen is poorly designed, it’s because we didn’t do the dishes after every meal. Michael Feathers recently wrote an eerily similar entry about the professional chef’s concept of working
code refactoring
I often encounter code like this: if (rowCount > rowIdx) { if (drc[rowIdx].Table.Columns.Contains("avalId") { do { if (Attributes[attrVal.AttributeClassId] == null) { // do stuff } else { if (!(Attributes[attrVal.AttributeClassId] is ArrayList)) { // do stuff } else { if (!isChecking) { // do stuff } else { // do stuff
software development concepts
In a previous entry, I touched on the broken window theory. You might be familiar with the Pragmatic Progammers’ take on this: Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to