Hit 'reply' on the wrong post - SpikyOrange specifically insinuated
curly-brace-free if statements are an abomination. To which I say:
pah!
Ben Schultz: They add clutter. Therefore, the onus is on you and not
on me - you need to prove why they are worth it. It would be silly to
ask me to prove why they are NOT worth it - then what's to stop you
from requiring that I prove why you do not need hungarian notation,
or, heck, commenting every line with a funny, unrelated joke. Note
also that the original poster I was trying to reply to (SpikeyOrange)
made this claim:
> For me it is as confusing and dangerous as when someone
> uses an if statement in Java without curly braces. I mean, c'mon, it's
> only a couple of braces ("it's only a return statement..."), but the
> danger of maintaining that code incorrectly [...]
Who's not leaving whom alone, here?
> [case statements in blocks]
You know, aesthetically, that wins. Unfortunately the auto-formatter
of eclipse bollockses that right up. Also, just because you have your
shiny block there, it doesn't mean your block auto-breaks. Which could
lead to confusion - mentally it LOOKS LIKE a for/if kind of block,
which don't just fall through, so I guess that's why it's technically
a bad idea. As a total sidenote, I never indent my case/default
statements; semantically they 'go with' the switch statement. This is
analogous to not indenting an 'else' relative to the correlated 'if'
statement.
> [coin proposal to do away with requirement to brace try/synchronized]
Yes, there was one. It was hand-waved away with a mix of 'not enough
gain relative to likely problems retrofitting the parser' (a fair
argument) and 'not enough people use this' (a silly argument. Of
course nobody uses it - it's not legal. Joe Darcy, nor anyone else at
sun, knows how many people would or would not prefer things that way).
I let it go, mostly because the first argument was quite sound, and I
sort of get what Joe was driving at: there remains a lot of dogged
adherence to the 'curly-brace-free blocks are EVIL! EVIL I TELLS YA!'
"style rule" - which is likely to cause a lot of unfounded complaints
if such a feature (that is, allowing brace-free try/synchronized) is
ever added to java, and the benefit was not worth the misplaced anger
it would probably cause.
On Sep 9, 5:28 pm, Jess Holle <je...@ptc.com> wrote:
> I think you meant to reply to something else as I never mentioned braces.
>
> Moreover I really, really dislike having braces around single line if,
> else, for, etc, blocks -- and never do in my code. I agree, that an IDE
> and reasonable indentation should show the error in your ways -- rather
> than pre-emptive clutter with unnecessary braces.
>
> [Of course I add extra braces where I want to explicitly limit the scope
> of variables, but that's different :-)]
>
>
>
> Reinier Zwitserloot wrote:
> > If you're scared of creating bugs due to a lack of braces (e.g. you
> > add a line and the code is not properly indented), you're doing it
> > very very wrong. That should not be a worry in a proper development
> > environment.
>
> > auto-format is your friend.
>
> > --Reinier "I have loads and loads of single statement unbraced if/
> > elses, and it's NEVER EVER caused a problem" Zwitserloot
>
> > NB: Unless you've tried it, I don't want to hear about whines.
>
> > On Sep 9, 1:55 pm, Jess Holle <je...@ptc.com> wrote:
>
> >> Casper Bang wrote:
>
> >>>> I'm not sure what you mean. There are no annotations in JavaFX
>
> >>> Sorry, from an earlier entry I inferred that there were
>
> >>>> It's enough to drive one absolutely batty.
>
> >>> So is JDBC's index-by-1 nature in bind variables.
>
> >> Agreed! Everything else in Java is index-by-0, why should the JDBC API
> >> be different?
>
> >> That said, most everyone has experienced index-by-1 and can deal with
> >> that in a system integration API like JDBC. The many hoops one has to
> >> jump through just to do a logical "setDouble(NaN)" or to set a null are
> >> amazing -- and all undocumented at a JDBC level except for the need for
> >> the 2 and 3 argument versions of setNull(), which just seem silly (null
> >> is null -- no data type or type name needed).
>
> >> --
> >> Jess Holle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
