• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Sun's code conventions -- very flawed

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've noticed most Java books adhere to Sun's code conventions. I assume it must be because that old K&R style borrowed from C uses less vertical space. But a careful reading of Sun's conventions (the latest update was 1999) shows many errors, inconsistencies, and contradictions. I'm curious why that old coding style is being resurrected.

thanks
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But a careful reading of Sun's conventions (the latest update was 1999) shows many errors, inconsistencies, and contradictions.

Got a few examples?
 
Kevin Rainer
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>Got a few examples?

Yes. Here are a few obvious ones.

1.) Section 6.3: "Put declarations only at the beginning of blocks. (A block is any code surrounded by curly braces "{" and "}".) Don't wait to declare variables until their first use; it can confuse the unwary programmer and hamper code portability within the scope."

This statement is quite bogus. Declaring variables in the context in which they are used makes for clearer code. See Joshua Bloch's "Effective Java" for a good discussion of why minimizing the scope of variables helps make more reliable code. Furthermore, objects should not be instantiated until it's clear they are needed. And just what is an "unwary programmer"? And finally, "hamper code portability within the scope"? That is useless.

2.) Section 6.3 (bullet 2) "Open brace "{" appears at the end of the same line as the declaration statement"

Why? The trailing curly brace is what caused the readability problems in the example if-statements in Section 4.2. The opening curly brace on line by itself separates the (single line) body from the if-check. Inconsistent indentation would then not be necessary.

3.) Section 7.4 says: Note: if statements always use braces {}. Avoid the following error-prone form:
if (condition) //AVOID! THIS OMITS THE BRACES {}!
statement;

*BUT* 7.5 says: An empty for statement (one in which all the work is done in the initialization, condition, and update clauses) should have the following form:
for (initialization; condition; update);

Why should the if-statement always get braces, but not the for? That for-statement looks alot more error-prone than the if-check with no braces.

Anyway this is a small sample of the problems with Sun's code conventions. I fully support coding standards that are clear, consistent and produce readable code. I really don't think that Sun's document does that.

Kevin
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Kevein]: I'm curious why that old coding style is being resurrected.

Resurrected? It never died. Where have you been?

Responding to Kevin's second post:

1) I completely agree. It's one of the most ludicrous bits in the Sun standard. Though if you're forced to comply, you can usually factor out a new method whenever you feel like starting a new block. Or just start an anonymous block on the spot, which is always good for confusing newbies.

2) I disagree, but don't care enough to repeat the many past discussions on this. I imagine you could do a search on "braces" in this forum and a few others, and find all the discussion you may like. (Limit it to user 290 if you want more on my take.)

3) The only semi-inconsistency in your examples. Personally I abandon braces in if statements whenever I can get away with it, since I think they're ugly in either K&R or Pascal style. But I would never, ever advocate an empty for statement like that. Way too error-prone.

You left out the other one which I hate as much as #1: Sun allows mixing spaces and tabs for indentation. This is evil, evil, evil, period.

Having said that, I really don't have any problem reading code that uses Sun's standard (or something very similar), and I prefer it to several others I know of. (E.g. Coop <cough/>.) "Readability" is largely a matter of what you're used to, IMO.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) block doesn't mean method. Anything between curly braces is a block, and blocks should be short. Block in that definition is equivalent with scope.

2) that's an issue as old as structured programming and likely will never be resolved. People likely will never agree on which is better

3) for an if statement, it prevents problems when people add code to it at a later date. An empty for statement is a complete unit that isn't likely to change, there's no code that would go inside the braces at all.

As Jim says, it's what you're used to.
As long as some system is used consistently across a code unit it will usually work out, but don't go around changing code to suit your taste in coding style!
 
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) i echo Jeroen, a "block" is whatever's inside a pair of braces. i have no trouble with Sun's preference for variable declaration at the top of the innermost block they can be declared in, with one syntactic quibble: looping variables in for loops. those can get declared in the for statement, which is technically (by my and Jeroen's definition) just outside the relevant block.

2) i'm not touching this one with a thirty-foot pole. except to say, i'm a Python programmer; the whole problem would just go away if y'all just did away with braces.

3) no-braces if's are fine with me, IF AND ONLY IF the statement to be conditionally executed can be fit on the same line as the condition statement. having a line break there without braces is a recipe for confusion, and i feel it should be shunned. of course, this too just goes away in Python, hint hint...

empty for statements are an abomination, a C-ism that should be put out to pasture. we don't use Duff's Device any longer, and we shouldn't use empty for loops either. if by chance you do feel the need to use one, stick an empty block after it just to syntactically clarify that you wanted it empty, or else you risk playing mind-games on your readers.
 
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) I'll echo Jeroen and M Beck on this one, mostly. The variable declaration in a for such as:


The 'int i' is local to the for loop and not visible outside. This only works where the someMethod() is the side effect wanted, notice the ; at the end. If you actually are putting a line of code to run with the for you (by Sun standards) need to have the {}. I'll also echo M Beck that if I saw a for loop like that in code I would hunt down the developer and smack him.

2) Umm, ya. Not going there.

3) Personally I always put {} after an if even if the line is
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
true, but I would not smack him (I'm not automasochistic ) when he did something like
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I'll be glad to smack both of you. There's no good reason IMO not to replace that with something more conventional and thus easily understandable:

(Insert additional braces or not; I don't care.) The important point here IMO is that everything in the for statement is directly related to incrementing the loop index. Everything else (which is related to doing something with a particular loop index) is inside the loop. If you want to know how many times the loop executes, or what values i has while it executes - all the info you need is in the for statement. What the loop does with each i - that's what's inside the loop. I strongly favor separating the iteration code from the doSomething() code, as they are (to me at least) very different things. About 98% of the time you need both looping logic and "doSomething(i)" logic. 2% of the time it's possible to sneak the doSometing() logic into the looping logic - but why is this a good idea? I think you're just sneaking imprtant logic into a context where it's likely to be overlooked. I don't see a big benefit here - I just see an increased likelihood that some people will overlook important code because they're not used to seeing this sort of loop. It's very, very easy to overlook a ; at the end of a line - remember how common this type of error was when you first learned Java or C/C++. Empty for statements are extremely likely to confuse new programmers, and it's asy to fix this by simply putting in an explicit block for any for statement. Even if it's an empty block. IMO of course.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not automasochistic

Is there some word for masochism which is not directed at oneself? As far as I know, all masochism is automasochism.
[ June 08, 2005: Message edited by: Jim Yingst ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My guess is that the difference is that the masochist likes to use the services of the sadist, while automasochist does it all by himself.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:
Well, I'll be glad to smack both of you. There's no good reason IMO not to replace that with something more conventional and thus easily understandable:
<snip>...
Empty for statements are extremely likely to confuse new programmers, and it's asy to fix this by simply putting in an explicit block for any for statement.



In general I agree with Mr Yingst. Stuffing as much as possible into a for loop often seems like a macho exercise.

Having said that, I've oozed testosterone every once in a while. But I'll still show some consideration for others and I'll make the no-op statement explicit by throwing it on its own line (I don't use braces on single-line blocks since I have tests for everything):



This is not out of consideration for new programmers. Instead, it's for anyone who might waste time by not immediately spotting the no-op when they read the code. I don't believe in dumbing down code to accommodate newbies, but I do believe in simplifying code to make it easily maintainable.

Oh yeah--I also believe we could all use a bit more figurative smacking. ;-)

-Jeff-
 
Yeah, but is it art? What do you think tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic