Sure, they're evil, but are they more or less evil than tabs?
Also, Joe was a bit misleading about annotations and preprocessors. Annotations can be used to manipulate most things as if there was a preprocessor. The Java compiler has certain constraints for annotations, but those constraints aren't there for post processors, agents, class loaders, or indeed -- a preprocessor.
Why all these developer-specific workarounds or 3'rd part preprocessors when Java could provide this functionalty natively in its officiel stack? I still think annotations would be an obvious way to allow for it. As Curt point out, I am not talking about storing semantics in the byte-code, but communicate include/exclude intension with the parser/code-generator.
I know that its common in Java to dump just about anything into external properties files and access these through classloaders, but I fail to see how the "impossible to use analysers and do refactoring" statement is relevant. And a pre-processor only in ME? Great, an even more segmented language, ironic that Java actually set out to get away with this the first place (SE, ME and EE are so different it might as well be 3 separate languages).
Its such double standards. One one hand everything has to be 100% abstracted, over-enginnered and "patterned" while on the other hand development-effeciently, KISS and transparancy is in demand (Examples off my head: EJB3 JPA, Matisse/GroupLayout, Simplice/VB).
And on a sidenote. Tabs are not evil, only apps which depends on specific enterpretation are (ViewCVS). You want to express an indentation, not that the next block should have 8 space chars beforehand rather than 4.
Great with this forum to open up and expand on posse debates. Good initiative Dick.
I tried to reply to your blog but again the goofy simple math question isn't working. (yes, I can add two numbers.) That "feature" has simply got to go; I get the same math question for every blogs.sun.com blog entry and of course its never the correct question. (or perhaps 43 + 4 != 47 at sun.com)
Anyway.
Here's what I was going to say about the tabs on your blog.
=== Tabs are only bad if you mix tabs & spaces.
The rule I give my programmers is this:
Use tabs to indent only; Use spaces afterwards, always.
never tab after a space; never space before a tab;
This allows everyone to use the tabwidth they find most pleasing visually, individually, while maintaining source code compatability with everyone else. I've written checkstyle rules that verify these rules and we hold each other to them.
I'm not sure why the math validation isn't working for you; it's a standard part of the Roller web logging software (which is deployed at blogs.sun.com) so there is nothing I can do about it.
The point I was trying to make is that despite rules, it's easy to make a mistake when you use two different kinds of whitespace characters in your source code. It sounds like you've found a way to catch these using checkstyle, and make everyone go back and fix it. I've never found the individual tabwidth preference particularly convincing. If they can't get along with the standard tab width, how do they get used to all the other parts of "code culture" - where to place braces, no spaces before function argument list parentheses etc. etc.? It all fits together, and four character indentation is in my opinion good Java code style practice.
I could write a blog entry called "Spaces are evil" but that would hardly solve anything. There is just too much religion in software development. Windows vs. Linux, KDE vs. Gnome, .NET/Mono vs. Java, tabs vs. space etc. This last one has to be the dumbest of them all. Forget about emposing "one truely correct style" because it obviously does not exist. While I have preferences for tab indentation and horizontally aligned brace blocks, I have no right nor desire to impose this on a legacy/VI practitioner from the Java 1.0 days.
With a pre-commit formating hook into SVN, a global policy can be upheld leaving developers to freely reformat checked-out code according to their preference and IDE. Some embedded diff tools (e.g. in JDeveloper) might not appreciate this, but at least now there will be no more moaning from purists.
As Jeremiah points out, practioners of the tab indentation rarely, if ever, start to use space unless being inside a statement.
Casper Bang wrote: > Forget about emposing "one truely correct style" because > it obviously does not exist.
Well put, Casper! I remember thinking the same thing when I first read the "official" Java coding standards document from Sun. I mean, congrats on inventing such a great language guys, but what makes them the world authority on coding style?
So in support of Casper's argument, the universal code style convention is never going to happen. You can't (and shouldn't) make the whole world follow anyone's preference.
If you want to enforce a certain style, become a development team leader and mandate it. Otherwise, obey the style that has been mandated to you.
And it's so easy to do! On my team, I set up my IDE code formatting config to the team standard, then export those preferences to a shared directory, and all the team members import them into their IDEs. Then the rule is simply, "always use the IDE's format function immediately before committing your code". We use tabs for indenting, but it's OK because the IDE controls all the indenting. So everyone's happy. (Even Tor)
In fact personally, I take it a step further and now rely on the IDE's formatting even while banging out code. I'll just type it in whatever way lets me get my idea out fastest (even if it completely screws up the formatting), then hit my format code shortcut key as instinctively as I hit Ctrl+S and it magically becomes beautiful. This has got me into a nice, short, "code, format, check" cycle that I find very efficient.
