Reply to Message
Expect the Unexpected
One of the "housekeeping tricks" learned the hard way - never assume. Use the "else" at the end of a logic chain as a catch-all for anything unexpected. Call it "Code Rot" because a dependency was overlooked, but these things do happen.
For example, If a function has an argument that should be passed with an integer value in the range 1-4, don't code it as "case 1", "case 2", "case 3", and "else"
Instead, code "case 1", "case 2", "case 3", "case 4" and "else" - and "else" raises an error about unexpected input.
In IF-THEN-ELSEIF logic do the same - leave the unspecified "ELSE" as "There should be no way to get here" and raise an error.
Then, after a missed project meeting and someone forgot to tell you they defined a new option in that meeting, you will find out right away, rather than trying to figure out what you weren't told. Or many years later, when a routine that has "worked perfectly for years" gets something new, it tells you right away.
Been there. Done that. Got a tee-shirt. Don't need another tee-shirt.
For example, If a function has an argument that should be passed with an integer value in the range 1-4, don't code it as "case 1", "case 2", "case 3", and "else"
Instead, code "case 1", "case 2", "case 3", "case 4" and "else" - and "else" raises an error about unexpected input.
In IF-THEN-ELSEIF logic do the same - leave the unspecified "ELSE" as "There should be no way to get here" and raise an error.
Then, after a missed project meeting and someone forgot to tell you they defined a new option in that meeting, you will find out right away, rather than trying to figure out what you weren't told. Or many years later, when a routine that has "worked perfectly for years" gets something new, it tells you right away.
Been there. Done that. Got a tee-shirt. Don't need another tee-shirt.
Posted by oldbaritone
11th Oct 2011
