10 Practical but Paranoid Java Programming Techniques

[[147453]]

After you've been coding for a while (I've been programming for about 20 years now), you start to get used to it. Because, you know...

Anything can go wrong, yes, it does.

That's why we need to adopt "defensive programming", that is, some paranoid habits. Here are my 10 most useful but paranoid Java programming techniques. Let's take a look:

1. Put the String string first

In order to prevent occasional NullPointerException exceptions, we usually place String on the left side of the equals() function to implement string comparison, as shown in the following code:

 // Bad  
 if (variable.equals( "literal" )) { ... }
 //Good  
 if ( "literal" .equals(variable)) { ... }

This is something you can do with your head, rewriting the expression from the Bad version of the code to the Good version of the code, and nothing is lost in the process. Different opinions are welcome...

2. Don’t trust early JDK APIs

In the early days of Java, programming was a painful thing. The APIs were still very immature, and perhaps you have come across the following code block:

 String[] files = file.list();
 // Watch out  
 if (files != null ) {
 for ( int i = 0 ; i < files.length; i++) {
 ...
 }
 }

Seems paranoid? Maybe, but look at the Javadoc:

If this virtual path does not represent a folder directory, this method returns null. Otherwise, it returns an array of strings, each string representing a file or folder in the directory.

Yes, that's right. We can add some validation:

 if (file.isDirectory()) {
    String[] files = file.list();
 // Watch out  
 if (files != null ) {
 for ( int i = 0 ; i < files.length; i++) {
 ...
 }
 }
 }

3. Don’t trust “-1”

I know this is paranoid, but the Javadoc for the String.indexOf() method clearly states: The index of the first occurrence of the specified character in the object. If it is -1, it means that the character is not in the character sequence.

So it is natural to use -1, right? I say not, please look at the following code:

 // Bad  
 if (string.indexOf(character) != - 1 ) { ... }
 //Good  
 if (string.indexOf(character) >= 0 ) { ... }

Who knows. Maybe by then they've changed the encoding to be case insensitive, and maybe returning -2 would be a better approach? Who knows.

4. Avoid accidental assignments

Yes. This probably happens quite often.

 // Ooops  
 if (variable = 5 ) { ... }
 // Better (because causes an error)  
 if ( 5 = variable) { ... }
 // Intent (remember. Paranoid JavaScript: ===)  
 if ( 5 === variable) { ... }

So you can put the comparison constant on the left side, so that no accidental assignment errors will occur.

5. Check Null and Length

Regardless, whenever you have a collection, array, etc., make sure it exists and is not empty.

 // Bad  
 if (array.length > 0 ) { ... }
 //Good  
 if (array != null && array.length > 0 ) { ... }

You don't know where these arrays come from, maybe from an earlier version of the JDK API, who knows.

6. All methods are final

You may tell me your open/closed principle, but it's all bullshit. I don't trust you (correctly inheriting all subclasses of my parent class), and I don't trust myself (accidentally inheriting all subclasses of my parent class). So strictly use final for methods that have clear meanings.

 // Bad  
 public   void boom() { ... }
 // Good. Don't touch.  
 public   final   void dontTouch() { ... }

7. All variables and parameters are final

Like I said. I don't trust myself (not to accidentally overwrite my values). That being said, I don't trust myself because...

…which is why all variables and parameters are final.

 // Bad  
 void input(String importantMessage) {
 String answer = "..." ;
    answer = importantMessage = "LOL accident" ;
 }
 //Good  
 final   void input( final String importantMessage) {
 final String answer = "..." ;
 }

8. Don’t trust generics when overloading

Yes, it can happen. You believe you wrote this super nice API and it's intuitive, and along comes some user who just casts primitives to Object until the damn compiler stops whining, and suddenly they're linking against the wrong method, thinking it's your fault.

Look at the following code:

 // Bad  
 <T> void bad(T value) {
    bad(Collections.singletonList(value));
 }
 <T> void bad(List<T> values) {
 ...
 }
 //Good  
 final <T> void good( final T value) {
 if (value instanceof List)
        good((List<?>) value);
 else  
        good(Collections.singletonList(value));
 }
 final <T> void good( final List<T> values) {
 ...
 }

Because, you know... your users, they're like

 // This library sucks  
 @SuppressWarnings ( "all" )
 Object t = (Object) (List) Arrays.asList( "abc" );
 bad(t);

Trust me. I've seen it all. Including the following

This kind of paranoia is still good.

9. Always throw exceptions in the Default of the Switch statement

Switch statement… one of those ridiculous statements I don’t know whether to stand in awe or cry over, but anyway, since we insist on using switch, we might as well use it the best way possible. Take a look at the following code:

 // Bad  
 switch (value) {
 case   1 : foo(); break ;
 case   2 : bar(); break ;
 }
 //Good  
 switch (value) {
 case   1 : foo(); break ;
 case   2 : bar(); break ;
 default :
 throw   new ThreadDeath( "That'll teach them" );
 }

When value == 3, a prompt will appear saying that the file cannot be found, instead of confusing people.

10.Switch statement with curly braces

In fact, switch is the most evil statement, like some people who are drunk or lost in gambling wrote the code, see the following example:

 // Bad, doesn't compile  
 switch (value) {
 case   1 : int j = 1 ; break ;
 case   2 : int j = 2 ; break ;
 }
 //Good  
 switch (value) {
 case   1 : {
 final   int j = 1 ;
 break ;
 }
 case   2 : {
 final   int j = 2 ;
 break ;
 }
 // Remember:  
 default :
 throw   new ThreadDeath( "That'll teach them" );
 }

In a switch statement, each case statement has a scope of only one line of statements. In fact, these case statements are not even real statements. They are like jump labels in a goto statement.

in conclusion

Paranoid programming may seem weird sometimes, because the code often turns out to be a little more verbose than what is needed. You might think, "Oh, that will never happen", but like I said. After 20 years or so of programming, you don't want to just fix these stupid bugs because the programming language is so old and flawed. Because you know...

Now it’s your turn! What’s your most obsessive programming quirk?