Summarize ten practical but paranoid Java programming techniques

preface

When you immerse yourself in coding for a period of time (for example, I have invested nearly 20 years in programming), you will gradually get used to these things. Because, you know... Anything can go wrong, yes, it is.

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

1、 Put the string first

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

This is something you can do with your mind. From the code rewriting expression of bad version to the code of good version, nothing will be lost. Welcome different views

2、 Don't trust the early JDK API

In the early days of Java, programming was a very painful thing. Those APIs are still immature, and you may have encountered the following code blocks:

Looks paranoid? Maybe, but look at Javadoc:

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

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

3、 Don't believe "- 1"

I know this is paranoid, but string. In Javadoc The indexof () method clearly indicates the position index of the specified character for the first time in the object. If it is - 1, it means that the character is not in the character sequence.

So it's natural to use - 1, right? I'm not right. Look at the following code:

Who knows. Maybe they changed the encoding method and did not distinguish between case and string. Maybe a better way is to return - 2? Who knows.

4、 Avoid accidental assignment

yes. This may happen often.

So you can put the comparison constant on the left, so that there will be no unexpected assignment error.

5、 Check null and length

Anyway, as long as you have a set, array, etc., make sure it exists and is not empty.

You don't know where these arrays come from. Maybe they come from an earlier version of the JDK API. Who knows.

6、 All methods are final

You may tell me your open / close principle, but it's all nonsense. I don't believe you (correctly inherit all the subclasses of my parent class) and I don't believe myself (accidentally inherit all the subclasses of my parent class). Therefore, for those methods with clear meaning, we should strictly use final identification.

7、 All variables and parameters are final

Like I said. I don't believe in myself (don't accidentally overwrite my value). That said, I don't believe in myself because

... that's why all variables and parameters are final.

8、 Don't trust generics when overloading

Yes, it can happen. You believe that the super nice API you write is very intuitive. With it, some users who just convert the original type to object type until the damn compiler stops complaining, and suddenly they will link the wrong method and think it's your fault.

Look at the following code:

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

believe me. I've seen all this. Including the following

This paranoia is good.

9、 Always throw an exception in the default of a switch statement

Switch statements... One of them is ridiculous. I don't know whether to fear it or cry, but anyway, since we insist on using switch, we might as well use it perfectly. See the following code:

When value = = 3, there will be a prompt that cannot be found, which will not let people know.

10、 Switch statement with curly braces

In fact, switch is the most evil statement, like some people who are drunk or lose gambling are writing code. See the following example:

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

summary

Paranoid programming seems incredible, sometimes because the code often proves to be a little more detailed, but not required. You might think, "Oh, this will never happen," but as I said. After about 20 years of programming, you don't want to just fix these stupid bugs, because the programming language is so old and flawed. Because you know

The above is the whole content of this article. I hope the content of this article can bring some help to your study or work. If you have any questions, you can leave a message.