Static Imports are Evil
Michael Santos explores a few features of Java 1.5. As part of it he uses the new static import feature and asks what people think of it. I think it’s the most evil invention in coding I’ve seen since while (++i < 5) type statements.
If you saw the line of code:
long time = nanoTime();
where is the nanoTime() function? In 1.4 and below it is obviously in the current class - in 1.5 it could be anywhere and the only way to find out is to scroll all the way back up to the top of the file and read through every import statement. Then consider something like:
err.println("Hello world.");
Where’s the print statement? Everyone knows about System.err.println so that must be it, unless err was a debug statement declared at the top of the file…
Is it really that difficult to type System.nanoTime() instead of just nanoTime()? Programmers seriously need to learn some more discipline instead of always taking the easy way out and forgetting about the guy who has to read the code after them.
In about 3 years time when I actually get to use Java 1.5’s features (backwards compatibility being as important as it is), the first thing that will be added to my coding guidelines will be no static imports - right next to no ++i or i++ embedded in other statements.
February 6th, 2004 at 5:51 pm
Gah. You’re dead right, that -is- a dumb design.
Perhaps they’ve come to the realisation that clearly, Java does not permit enough of the kinds of scoping errors which are required in the How To Write Unmaintainable Code guide…
February 6th, 2004 at 7:05 pm
If they keep this up, java won’t be java anymore…
February 7th, 2004 at 1:02 am
I think the theme to remember here is that your code will be written once, but read many times. You might save yourself a few seconds here and there by not having to type “System.” (etc.) but you’ll pay for it several times over when you, or another developer, has to go back and read that code down the road.
Static imports for constants might be a bit more acceptable than for methods, but even that is questionable.
November 4th, 2006 at 4:31 pm
I completely disagree, a programming langauge should facilitate writing *and* reading. You shouldn’t have to type redundant text all over the place. That is exactly why I hate java. If you want someone to be able to easily read your code, first of all it doesn’t help much to include the “System.” since one could easily look up nanoTime() in the documentation. Second of all, code you write should be transformed into code others read - so that one can both easily write, and easily read code. An extra “System.” is not a second of lost time, it is hours of lost time over a year - and an annoyance at that. Forcing programmers to “learn some dicipline” goes against the very purpose of computer automation.
November 4th, 2006 at 5:10 pm
BT: You need to set up your IDE better - autocomplete makes it trivial to type System. and if you don’t want to, just make nanoTime() a macro to insert System.nanoTime(). Writing speed of a language is irrelevant compared to the readability of that language. “hours of lost time over a year” is irrelevant compared to the amount of time lost to writing code that isn’t easy to read.
July 3rd, 2007 at 11:21 pm
I tend to agree with the above examples.
On the other hand, this is much more readable with static imports :
new GridBagConstraints(0, 0, 1, 1, 1.0, 1.0, CENTER, BOTH, new Insets(0, 0, 0, 0), 0, 0)
as well as this :
Color c = BLACK;
But I also tend to agree that Java was constructed to avoid awkward code as in your examples, so I’m generally against static imports.
August 28th, 2008 at 2:31 pm
I absolutely agree; it is just downright evil as the post says to do static imports; talk about all this being ironic. A feature invented to compensate for an anti-pattern in a language results in a worse anti-pattern %=).
Regards
Vyas, Anirudh