Debating the Value of Writing Good Code – Amazing
I just got done talking to my two teammates about the value of defensive coding. Specifically, that there is value in Java of checking the value returned from every method call - including the JVM's new operator. I'm stunned that these guys believe that it's "silly" to check for things like that. I say, that's the bloody point of checking things in code. Have they not read Code Complete? Have they never really built large, critical systems that simply didn't have the option of failing?
My guess is, the answer is No.
In my code, you'll see a lot of code that looks like this:
/** * This method returns the reference to the BKIRCProtocol that is * going to be monitoring the traffic from the IRC Server while we are * connected to it. If there is no listener defined at the time this is * first called, then create one because we really need to have it. */ public synchronized BKIRCProtocolListener getListener() throws BKException { if (_listener == null) { _listener = new BKIRCProtocolListener(this); if (_listener == null) { throw new BKDebugException("BKIRCProtocol.getListener() - no protocol listener was present and one could not be created. This is a serious Java allocation error and needs to be looked into."); } } return _listener; }
Where I follow a new with a test for the resultant against null. It's standard coding style for me. When I was at First Chicago, I had the great fortune to work with an incredible group of guys. They were pivotal in having me look at coding as something a group can do as opposed to a series of individuals. In that group, I learned the value of having the code look like one mind wrote it. Debugging and fixing was as easy for one as it was for all. The style wasn't exactly mine, but we agreed on one for the group, and it stuck. It was great.
I have been trying to re-create that kind of experience and to some extent, I've been able to succeed in very limited cases. But I have seen it again. When you look at coding as not your work, but the team's work, you start to see that there's more to it than what you think. You care about the next guy getting the call to fix a problem you might have created. But when you write as a team, it's impossible to tell who wrote it, and that makes debugging vastly easier.
I guess I'm just surprised that I'm talking with developers making six-figures and they are talking about "how often" in the error checking. It's just stunning. You only have to write it once, and then it's always going to be there. That's the "how often" you need to focus on.
Expect more. Build it better than it has to be.