My paranoid defensive programming style

From JQuantLib

In this article I present some defensive programming techniques which sometimes people disagree. Here I try to explain or even justify why I'm so paranoid :) Let's see if I convince you... If I'm successful, you will not only become a paranoid defensive programmer like me, but your applications will be safer and converge to production quicker!

Foreword: we are all humans

Programmers sometimes think they are super humans, more intelligent than everyone else around, much more aware of details and less prone to failure. Well... I disagree. I think we are all humans and we are all subject to make some mistakes, forget things and get confused sometimes.

Maybe I'm wron or talking for myself only: maybe the majority of programmers remember the entire ASCII table, all hex instructions codes of iAPX386, all HTTP error codes, all keywords of Cobol language and so on. OK, ok, you will tell me that all these things are outdated and/or we don't need to remember. Yes! This is exactly the point: information has importance during a certain period of time and after that it may not be important anymore; it can be forgotten, leaving room inside your head for more important things.

Yes! This is why we need to emply defensive programming techniques against ourselves: because we don't know exactly when the garbage collector inside our heads will decide something is not needed anymore and decides to throw information away. This is exactly the point: employing defensive programming, your code will work well even if you forget things or simply get confused face a certain situation you were not expecting to see.

Use "private" by default

I'd say that it's more or less common sense nowadays that all variables should be private unless for a very good reason. Unfortunately, if you forget to specify private, protected or public, Java assumes that a field or method is package private (the default protection), which means that classes from the same package can freely access your variables. IMHO this is highly undesirable for only one reason: if there's no access modifier keyword, we cannot tell for sure if you intentionally left your code without it or if you forgot to mention it. The compiler should oblige us to specify something. The verb forget here is the point: if you forget, you potentially insert a bug or a security breach into your code.

I have a friend who strongly disagrees of me. He not only uses default package protection everywhere but he also expose fields (using the public keyword) much more than anyone else I've ever met. We had very long chats about all these stuff and we never agreed about anything, or almost anything. He told me that in GUI programming it's very handy to expose internal components, attributes, etc because objects in this context are mostly containers which group resources a programmer is interested on and should have easy access to these resources. OK, I partially agreed, but with restrictions. And that's all.

I use to present the following metaphor: Do you grant access to your fridge? I mean... the fridge you have at home... who has access to it? Your kids? Your neighbors of the same floor, all your neighbors of all floors? The entire street? The entire country? All 6 billion people in the world?

Probably you will tell me that your family has access to it and noone else should touch it. OK. So... why on hearth should we give access to our fields to classes of the same package? If there's a very good reason, I can understand, but I cannot understand any reason for thinking that this should be the default behavior.

You may say that a package is written by someone and no extraneous class belongs to that class. This is wrong. You can declare any package you like and you can declare any class name you like. By providing a specific CLASSPATH with a certain sequence, you can tweak other packages classes and even system classes. This will give your classes access to internal stuff from classes "of the same package", allowing you to change other classes behavior.

First recomendation:

Employ private and avoid your yogurt to be stolen from your fridge.

If you are in doubt, use private anyway. If needed, the future will tell that you need to change it. Otherwise... well... you already employed the correct access modifier since the day one. Congratulations: you've already just prevented several bugs and security holes! :)

(more to come)

Richard Gomes 21:35, 30 September 2009 (UTC)