How to do Conditional Compilation with Java

[cur...@gmail.com]

Here's another discussion about Java prepressors.

"How to do Conditional Compilation with Java"
http://weblogs.java.net/blog/schaefa/archive/2005/01/how_to_do_condi_1.html

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.

[Casper Bang]

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.

[Tor Norbye]

I tried to address the tabs issue here:
http://blogs.sun.com/tor/entry/tabs_are_evil_part_3

-- Tor

[naik...@gmail.com]

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.

It works quite well.
===

Jeremiah

[Tor Norbye]

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.

-- Tor

[Casper Bang]

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.

[naik...@gmail.com]

Yeah, you make a good point there, Tor.

[Will]

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.

Can we just agree to disagree?

Cheers,
Will.