Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
darknighte
Is this you? Claim Profile »
8 months ago
in Death to Nil on Virtuous Code
Interesting point. I would like to offer a couple of additional considerations.
First, being paranoid (or having an insecurity complex) during development can help prevent code from "working" until the 11th hour. Healthy use of asserts to check for NULL's in this case can be a good thing. Secondly, not all problem domains are the same. In the embedded and/or safety critical space, severe damage can result based on unexpected values propagating through code even during development. By working with the first point, significant and costly damage can be avoided (and, in my case, has been more than once.) So, in my case, I try to balance the compulsive (can you say OCD anyone?) checking against out of bounds values against the impact to performance. Specifically, I use assert() heavily to validate initial code passes in development and then disable the assert() when I judge code to be more stable. Of course, this is always a judgment call for any coder/designer.
First, being paranoid (or having an insecurity complex) during development can help prevent code from "working" until the 11th hour. Healthy use of asserts to check for NULL's in this case can be a good thing. Secondly, not all problem domains are the same. In the embedded and/or safety critical space, severe damage can result based on unexpected values propagating through code even during development. By working with the first point, significant and costly damage can be avoided (and, in my case, has been more than once.) So, in my case, I try to balance the compulsive (can you say OCD anyone?) checking against out of bounds values against the impact to performance. Specifically, I use assert() heavily to validate initial code passes in development and then disable the assert() when I judge code to be more stable. Of course, this is always a judgment call for any coder/designer.
2 replies
avdi
Having worked in the embedded space, I'd say that that is where it becomes essential to get rid of this kind of coding insecurity complex. If you're checking for null in domain logic it means you aren't checking for it at the boundaries religiously enough, using preconditions, postconditions, and invariants. Something I've done in the past, if an API I had to to use might conceivably return a null, was to wrap that API in a wrapper of my own that always asserts that the return values are non-null. And then only talk to the API through that wrapper - a software condom of sorts. I'm OK with implicit pervasive null-checking of this nature - it's when the conditionals for null checking are mixed into the conditionals for business logic that the code starts to smell funny.
avdi
On a second reading I think we're mostly on the same page. I don't really have a problem with using assert() a lot. assert() isn't a conditional - it says "I never, EVER expect this to be null". I don't have to write a unit test to test that my code handles the null and non-null cases correctly, because the null case will always crash. What I'm advocating against is code that tries to handle nulls as an expected case.
