I may have missed the mark on my attempt at an over the top, yet at least vaguely humorous reaction to Marc’s comments about explicit or implicit imports in Java.
The golden rule of coding styles should apply: do what the rest of the team is doing.
Having said that, I have to point out a couple of things in response to Marc’s update:
Code get’s read (at least) 100 times more then it gets written. (Forgot where I catched this quote) So the bit of time *you* win in typing is asking for a tough pay-back on wasted time on reading/interpretation. Please abondon the idea that you are doing someone a favor.
Code gets read 100 times more than it gets written, but imports should never be handled by humans at all. Seriously, when I read Java code I never look at the import statements. Why would I? My IDE can read them, parse them and use that information far more efficiently and accurately than I ever could. It doesn’t care if explicit or implicit imports are used, it doesn’t care if it’s seen that particular package before or not. When I want to know what package a particular class is in I just hover the mouse cursor over it’s name and my IDE tells me the full package name. If I want to see the source of that class I control-alt-click the name of the class or usually the name of the method I’m interested in.
The use of implicit or explicit import statements only affects readability of those people who don’t have a decent IDE and those people are sacrificing so much in productivity that the type of imports used are the least of their worries. For the record, both emacs and vi can be configured to use ctags and get an understanding of the contents of your project’s source code, so you don’t necessarily have to abandon those if you find their keyboard shortcuts make you more productive. Emacs users however will probably find that most IDEs support emacs key bindings anyway.
When working in teams, you don’t want to be CTRL-O’ing in different styles to limit the amount of noise on cvs-diff lists.
This is only true if you don’t reformat the code into a standardized format before committing. You’ll actually find that if you run something like Jalopy over code as part of the CVS check-in process that diffs become more useful because the layout parts of the code are all standardised so the differences you see are actual changes to what the code does or how it does it. It’s not the way everyone likes to work and that’s fine, as I said above - do what the rest of the team does - but it is a viable option where you’re part of a team who are fairly firmly entrenched in using a two differing styles. Making a programmer change his coding style does reduce his productivity, depending on the programmer and how long he’s been using the current style will depend on how much of a productivity hit they incur.
And just to reiterate, the reason I prefer .* imports is because it reduces the number of interruptions while coding and the impact on readability is nil. If I were working with a very stubborn programmer who insisted on reading the import statements himself, apart from considering finding someone who makes better use of their time to work with, I’d switch to explicit imports without batting an eyelid. Okay, maybe just one eyelid, but definitely not two…
