|
Re: Offensive Coding
|
Posted: Jul 17, 2006 3:12 PM
|
|
> > I don't disagree with that but that is so context > > dependent that I can't help but have issues with a > > sweeping generalization like "Spurious null checks are > a > > symptom of bad code." As much as I probably sound like > a > > whiny prick, it's a testament to the respect I have for > > Michael Feathers that I even read the rest of the > article. > > My big problem with that is that where a lot of people > > would stop reading at that statement and that's why I > get > > so fired up about blogs and articles like this. > > Yeah, I don't know what to do about it either. The thing > is, I thought that I was avoiding misunderstanding by > saying this in my blog: > > "That’s not to say that null checks are wrong. If a vendor > gives you a library that can return null, you’re obliged > to check for null. And, if people are passing null all > over the place in your code, it makes sense to keep > putting some null checks in.." > > But, people will generalize. I don't know what to do > about that. It seems that it makes it very hard to talk > about some things.
What happened to the rest of the quote? "That’s not to say that null checks are wrong. If a vendor gives you a library that can return null, you’re obliged to check for null. And, if people are passing null all over the place in your code, it makes sense to keep putting some null checks in, but, you know what? That just means that you’re dealing with bad code: you're dealing with code where people are actively making extra work for themselves and making code brittle in the process."
How is that not a generalization on your part? People pass null == bad code is what I see there. As I said in a previous post, I've had several people come by and talk to me about this today and what they got from it is "Don't check for null". I've also had to fix plenty of code that would qualify as "stupid free" because it didn't check for null and then subsequently crashed, telling me that an instance of an object was not instantiated. So it had to get fixed. And, honestly, I don't have the time to refactor an entire code base to take care of an issue where somebody didn't make sure their input was valid, so the input gets validated in that instance where it is crashing. If I had to refactor every codebase I came across to be what I would consider "right", well, I don't want to work that long. :-(
There are also several instances in code I work on where null is a valid occurence and very different from an object, such as in your array example, that has no entries. In these cases we had to reduce overhead (mostly free memory that containted nothing but lots of empty structures) and pick up some performance. I keep hearing how arguments like these are red herrings and straw men, yet when I implement these changes I get from 15 - 60% performance improvements. Projects like this are why I agree with your assertion in theory but not in practice, as I also said.
And yeah, these things can be hard to talk about. Especially when you call people stupid. Or, maybe, more technically, tell people they write code that resides in a stupid zone. I have, and will continue to write, a lot of code that you would probably consider stupid, simply because I don't know where or how it is going to get used. Most of the code I've written I have almost 0 control over how it gets used so I have to be VERY defensive in my coding practices. So maybe I took your jab a little personally.
|
|