Caution: Starcraft 2 is addictive and may hinder blog post writing. End of public service announcement; returning to the scheduled programme in 3, 2, 1…

Recently, I've had two notable encounters of a specific topic that I simply need to address in the form of this blog post. Today's subject: Information hiding, i.e. making fields or methods something other than public.

After I read Code Complete a few years back, it simply dawned upon me why information hiding is totally awesome. But it seems that all too many programmers haven't read it, and therefore I have met people being confused by the idea. Not confused in the "what does it mean?"-way, but rather in a way that they can't see the point.

A couple of months ago, my brain got stuck on an idea. My brain often does that, and I can't really be at ease until I even try to realize that idea (this blog is definitely one of them). So, I went about uneasy for a good couple of weeks until I gave in: I decided to get myself a netbook. For coding.

A cornerstone of the test-driven development movement is to write the absolute minimum amount of code needed to get a certain unit test to pass. I like that idea. I like it so much, that I want it to be extracted from the TDD world for others to enjoy – no unit tests required.

Jim walks past my desk, on his way to the coffee machines. He gives a purposeful, not-very-subtle, sigh, so I reply to him with a "so, what's up now?"-look. He says he's hunting for a bug in a class that's over 1500 lines long, split up into a huge amount of private methods. He can reproduce it at will, so he knows pretty eactly where the bug is in within the application, but since he hasn't written the code, it's a jungle. So he's fetching his motivational cup of coffee, to get him started on finding where that code containing the bug is.

Since I'm somewhat familiar with his project, I could've asked for more details and then hazard a guess about what's wrong and where to start. Instead, my mouth goes off: "Yeah, but imagine what it would look like, if all those methods would be in-line?" I ask rhetorically. I then stubbornly continue, before Jim had the chance to interject to my unhelpful and unsymphatetic comment: "Instead of you having a couple methods of 500 lines each, you now have a handful of methods that are significantly shorter, each with a descriptive names about what they do."

"But it's just silly," Jim replies defeatedly. "If a method is private, and it's called from exactly one place for exactly one purpose, why can't it just be in-lined? This way I wouldn't have to jump and skip between methods to know what it does, and how it mangles the data? How else am I supposed to find the bug?"

And I realize that Jim has a point: Reading highly fragmented code to find a particular bug is tedious. But I refuse to say that my point is any less valid: Any one method is easier to read and understand the less code you have to decipher.

Unfortunately, it seems like we can't have it both ways.

Bob is already open source. But that's not enough. It's now open problem aswell!

I'm going to write down the design problems I've encountered with Bob in a public place. These design problems don't fit in a bug report system, since they're fluffy and abstract. A mere patch of code won't be enough to fix them. The idea is that once I've made a problem go away, I'll add a summary about what I did, or am going to do, about it.

"Why?" you might ask. Well…

First Reason

I'm very forgetful, so it's just a place to remember stuff. It's also helpful to get larger concepts down on paper to look at, as a whole. Additionally, the process of writing them down, forcing myself articulate the problem, makes the problem as defined as possible. This makes the weak points easiest to find, and subsequently concentrating an attack on those. This is, by far, be the most important reason.

Second Reason

I'm not the last person to write code, and once infinite monkeys start writing, they'll very soon encounter the same problems I'm dealing with. A few infinite monkeys might then find the wiki entries. By any luck, their problems are already solved, so they can just copy the solution off of that, and be done a bit faster. This is, by far, the most interesting reason.

Third Reason

As with open source, there's always the hope of contributions. I'm not the first person to write code, and the chances are that someone else has already encountered and solved the same problems I'm dealing with. By any luck, this good samaritan will edit the wiki page, and help me along the way. This is, by far, the most utopian reason.

So, go ahead, laugh at my problems. Or help a guy out. Feel free to edit the pages as you wish.