style guide

[Steve Lovelace]

Just had a look at the Java Style Guide (Chicken Coop) and was a little surprised. What's offered isn't Sun standard or OSF standard; doesn't look like most of the java I see; isn't how I like to write java, which is close to the aforementioned styles. So what gives? What style is this?
Where it departs most glaringly is in the placement of opening curly braces and use of whitespace between the elements of a statement. When I first encountered what I think is accepted java style, I appreciated its acknowledgement of the role of whitespace: it is the strongest separator - even stronger than a row of asterisks. Accordingly it uses whitespace sparingly and meaningfully. The spastic use of whitespace seen in styles where, for instance, the opening curly brace occupies a line of its own or parentheses are spaced apart subtly wears us down by spreading out the code and creating obstacles for the visually-oriented processors we carry between our ears. Surely java style isn't moving in this direction.

[Rufus BugleWeed]

I really like to doubleclick an identifier and have the text selected.
I think

cust_address = Adress.getAddress( customer_key, date, building_number );
is much easier to read than
custAddress=Adress.getAddress(customerKey,date,buildingNumber);.
IMO camel case sucks.
When I have to read code all day tracing a bug I think reading code with JR style guide spacing leaves my eyes less tired.
Ican'tfindmytechnicalwritingguidefromcollegebutitrecommendedplentyofwhitespace.
Theres a reason we put space between the tokens.

[Jim Yingst]

Well, I pretty much agree with Steve. Aside from the usefulness of whitespace as a visual separator when it's used sparingly, I like to have methods that fit easily on a single editor window even when I've got a lot of other windowns open in my IDE - so I dislike anything that inserts a lot of gratuitous spaces and newlines. Compactness is a virtue, IMO. I just use Sun's standard most of the time. The JavaRanch style guide is mostly used for the Cattle Drive - if you participate in that, you're expected to comply with the guide. This, I consider a good thing, even though I don't really like this particular guide much, as it's worthwhile for programmers to learn how to consciously control their style and comply with a (perhaps arbitrary) style guide. I just hope that people raised on the Coop guide don't get too upset when they see Sun-standard code; they certainly need to be able to deal with that too. But, if you're not in the Cattle Drive, I don't think it matters much anyway...
[ September 30, 2003: Message edited by: Jim Yingst ]

[Jim Yingst]

[Rufus]: I really like to doubleclick an identifier and have the text selected.
Yup, me too. What editors is this a problem with? I use TextPad and Eclipse mostly - selecting text is really easy.
[B][Rufus]:
I think

cust_address = Adress.getAddress( customer_key, date, building_number );

is much easier to read than

custAddress=Adress.getAddress(customerKey,date,buildingNumber);

[/B]
Note that Coop style would require whitespace after customer_key and data, as well:

cust_address = Adress.getAddress( customer_key , date , building_number );

And people typically just get used to putting extra spaces in places where they aren't required, e.g. before the final semicolon. :roll:
Note also that Coop style won't allow those pesky underscores - which I agree with. I might be OK with underscores if they were encouraged in the language to begin with, but they're not used in standard libraries (maybe there are some exceptions, but not much). So given that we've got camel case in much fo the code, and can't possibly get rid of it, I favor keeping it for identifiers we choose as well.
Actually I like mixed case, I just think the initial lowercase looks odd. This is something I like about C#, actually - they encourage "MethodName()" rather than "methodName()".
[ September 30, 2003: Message edited by: Jim Yingst ]

[Steve Lovelace]

I think
cust_address = Adress.getAddress( customer_key, date, building_number );
is much easier to read than
custAddress=Adress.getAddress(customerKey,date,buildingNumber);.
I believe Sun style would have us write:
custAddress = Adress.getAddress(customerKey, date, buildingNumber);
My take is that it should all be based on bio-mechanics. Our brains are amazingly adept pattern recognizers. Reading code involves a second process, parsing, which isn't all that natural to us and feels like work when we do it. The aim of style should be to enlist our pattern-matching talent in a way that optimally facilitates parsing. There is a tension between not separating logical wholes and making tokens easily distinguishable. And there is compactness - the less mechanical work the eye has to do, the better. For me, Sun style is close to optimum.
Oh, and I like camel case. That first capital isn't signaling anything, and I have to reach the shift key to type it. Recently did some VB programming where this is the style and found it very annoying.
But I have this other question which isn't about individual likes and dislikes. Is there a dominant java style? Maybe not, I don't know. But if there is, shouldn't the Coop be using it as opposed to something arbitrary? It isn't evident that the Coop is about the Cattle Drive. It appears to be a statement by the Ranch about how to write java.

[Jim Yingst]

Is there a dominant java style?
Sun's style is the most common, though there are plenty of exceptions.
For me, Sun style is close to optimum.
For me, Python is even closer. But Java keeps forcing me to use those damn curly braces.
Maybe not, I don't know. But if there is, shouldn't the Coop be using it as opposed to something arbitrary? It isn't evident that the Coop is about the Cattle Drive. It appears to be a statement by the Ranch about how to write java.
True, and in that context, I disagree with it. It fulfills three roles, as I see it:

Personal advice from Paul Wheaton, JavaRanch's owner and cofounder.

Required style for Cattle Drive participants

Required (expected? hopeful?) style for com.javaranch code

The last doesn't come up that often, but sometimes...
Personally I think there's value in forcing Java students to try at least two radically different styles long enough to get comfortable with them both, regardless of which they prefer. It's good for people to realize that having a curly brace at the end of a line, or the beginning, is really not that big a deal - just do what the spec says, and move on, and be prepared to see other code obeying other styles.
Anyway I agree the style page should really be placed in context more, IMO, (e.g. "this is primarily for Cattle Drive students...") but I leave that to El Jefe.
[ September 30, 2003: Message edited by: Jim Yingst ]

[Thomas Paul]

I agree with Jim and Steve. I never use the JR style guide. I actively hate it and require my students to follow the Sun standard. I feel that students should get in the habit of using the most common style. Starting the wrong way will get them in the habit of coding in what is not the generally accepted standard. The point about learning to follow a standard might make sense if most shops had a standard. The only shops I have ever been in that had a published standard were the shops where I created and enforced them (it's good to be king). So we teach programmers to follow an unusual standard; they carry that standard to their job; all the other little programmers make fun of them because they "code weird." Do we really want to send our children out into the world to be made fun of?
My opinion is that the JR standard is way to C-ish. It looks like something designed by a C programmer as opposed to a Java programmer. In fact, it looks exactly like the standard in my first C shop.
[ October 01, 2003: Message edited by: Thomas Paul ]

[paul wheaton]

I would argue that the JR standard is far from C-ish. If anything, it's smalltalk-ish and pascal-ish.
C code generally derives from K&R C, hence the use of K&R brace placement. The JR style guide uses "pascal style" brace placement. The braces line up as they would with Pascal "begin" and "end".
C code also goes with constants being all caps seperated by underscores. The JR guide goes along with the idea of OO: the fact that it is a constant does not need to be reflected in the identifier. It is an object and it's properties could change. If you are writing a terminal emulator, you might define "screenWidth" to be 80. You can declare it to be final because in all of your application the value never changes and the compiler may be able to perform optimizations on your code if you declare it to be final. In a later versiion, "screenWidth" could be set to 80 or 120, so you make it no longer final. Supposing there are 100 places throughout your code that depends on this value, you don't need to change those identifiers from "SCREEN_WIDTH" to "screenWidth". You simply remove the word "final" from the declaration.
This style guide was written when the sun style guide was in its infancy.
Naturally, I think this style guide is superior to Sun's. And there have been others that thought so too, and adopted it.
Many people have adopted it "mostly" - creating a document of exceptions for their group. Just as people have adopted Sun's guide "mostly".

[Thomas Paul]

Originally posted by Paul Wheaton:
I would argue that the JR standard is far from C-ish. If anything, it's smalltalk-ish and pascal-ish.

Perhaps, but it isn't Java-ish which is my main complaint. No matter how superior you feel your style is, it isn't the standard that virtually every Java programmer uses. I read a book a year or so ago where the author thought his style was better than Sun's. It was a fine style but it made his code difficult annoying to read because it wasn't the standard. The Java API should serve as your style guide. Code the way that the authors of the language code.

[Jim Yingst]

I agree with Paul W. that JR style seems less C-ish than Sun style does. And on the topic of constant names, I'd prefer if Sun had not followed C style. But given that they did, and many of these CONSTANT_NAMES are already going to be embedded in my code because I'm using standard libraries, at this point I prefer to follow Sun style for consistency.
I note too that the "official" Sun style was for some time presented on the Sun site as merely an example of a style guide, which had been developed by one particular work group at Sun. (And one could find plenty of exceptions to the guide looking through some earlier JDK versions.) The langauage was revised at some point to present it as the Sun style guide. Paul's correct that it was not so dominant when the JR guide first appeared, as it is now.
[Tom]: Starting the wrong way will get them in the habit of coding in what is not the generally accepted standard. The point about learning to follow a standard might make sense if most shops had a standard.
Well, experiences here vary. I acknowledge that many, many shops either have no standard, or have a standard which is not enforced. My favorites are the ones which have a standard which contains examples which do not even follow that standard. :roll: But there are also shops that do have a standard, or which at least go through a period where they pretend to have one, and I've seen people put up a lot of pointless resistance to anything that's different from what they were originally taught, and whine about other standards being "too unreadable". I believe that a lot of this is just that people haven't spent enough time looking at code that isn't organized the one way they're used to. Being able to adapt to other people's styles is a useful skill - for reading and writing.
I'll revise my position here to say I think it's good for programmers to have to, at some point, learn to code in a style significantly different from what they're used to. Maybe for one or two projects. If nothing else, get them to learn to use jacobe or something similar. Not while they're beginners though; wait until they're reasonably confident in other aspects of the language. And I'd prefer that Sun style be the one they learn first, as beginners.
[ October 01, 2003: Message edited by: Jim Yingst ]

[Thomas Paul]

Originally posted by Jim Yingst:
And I'd prefer that Sun style be the one they learn first, as beginners.

I agree 100%!

[Thomas Paul]

By the way, I disagree with you on the constants. I think it is important that we know which variables are constants because constants are assigned at compile time. If I compile my class and then someone changes the class with the compile time constant in it, I am not going to see that change of the compile time constant. Changing a public variable that is marked as a compile time constant is a violation of the interface contract because it has implications that may make my code fail months from now at recompile time.

[Jim Yingst]

I suppose I could go either way on the constants, if Sun's standard weren't already pre-eminent. And actually I have some questions about Sun's style here. The relevant section of the Sun guide says:

The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)

What's an ANSI constant? What's a class constant? I understand the "class" part, but not so sure about "constant". I'm wondering if they're referring to things initialized with compile-time constant expressions, or also to other things which are "constant" but not known at compile time. Or to things which are constant and can be known at compile time, but are not considered compile-time constants. E.g. Integer.TYPE is a Class, and no reference type other than String is a compile-time constant according to the JLS. So Integer.TYPE isn't a compile-time constant, yet it's all caps. Surely we don't want to consider any mutable type to be a constant, but perhaps immutable types are eligible? (And let's not overlook the Color class, with both Color.WHITE and Color.white, which mean the same thing. :roll: )
Simplest solution is to just assume they meant compile-time constants (consistent with your concerns above), and that examples like Integer.TYPE are simply in error. But it would be nice if Sun could've made this a bit clearer. And I'll be curious to see what standard they may recommend for enums, and whether they will be officially compile-time constants too.

[Thomas Paul]

Originally posted by Jim Yingst:
(And let's not overlook the Color class, with both Color.WHITE and Color.white, which mean the same thing. :roll: )

There are lots of examples of things like that in the API but they are mostly left over stuff that no one wanted to remove because they didn't want to break anyone's code. The programmers at Sun take the interface contract very seriously!

[Thomas Paul]

Originally posted by Jim Yingst:
What's an ANSI constant?

Carl explained that:
https://coderanch.com/t/386728/java/java/ANSI-Constants

[paul wheaton]

Originally posted by Thomas Paul:
Perhaps, but it isn't Java-ish which is my main complaint.

Ouch.
In my experience in working with lots of different teams, the styles I have seen are more often closer to the JR style guide than the sun guide. And that's before I've had a chance to make any influence.
Therefore, it would seem that my experience so far is radically different than yours.
Not everything from Sun is golden or perfect. As a case in point: the DTO vs. VO stuff.
As for looking to the API for standards, it would seem that somebody, at some point forced the issue and now Sun is attempting to stick to a standard. But when I worked for Sun, the code being developed did not stick to the standard. Again, it was closer to the JR guide than the Sun guide.
As for the constants: When was Color.WHITE introduced? Before, it was just Color.white.

[Jim Yingst]

Thanks for the ANSI link, Tom (and Carl). Presumeably ANSI constants can all be represented with constant class variables, initialized with compile-time constants, so that's easy enough.
There are lots of examples of things like that in the API but they are mostly left over stuff that no one wanted to remove because they didn't want to break anyone's code. The programmers at Sun take the interface contract very seriously!
Agreed. I didn't mean that the inconsistent APIs should be taken as evidence about how the style guide was meant to be interpreted; they were just examples of places where we find the types of maybe-constant variables I was talking about. If the Sun style guide had referred to compile-time contstants rather than mere constants, we'd have more to owrk with here.

[Jim Yingst]

In my experience in working with lots of different teams, the styles I have seen are more often closer to the JR style guide than the sun guide. And that's before I've had a chance to make any influence.
Therefore, it would seem that my experience so far is radically different than yours.
Agreed that it's quite possible for experienced developers to have very different perceptions of what's "standard" in the industry, depending where they've happened to work. In my own experience it seems like on the issue of opening curly braces, I've seen roughly equal amounts of both dominant styles. Lots of folks rebelled against the K&R style, while many others accepted it, and this fracture continues in Java. In other areas like Paul's mania for extra spaces everywhere , well, that doesn't seem to be so widespread in the industry. It's common to prefer

<font size="2">z = foo(a[x] + b, c) + d;</font>

to

<font size="2">z=foo(a[x]+b,c)+d;</font>

(and in fact this preference is supported by Sun), but I've rarely seen a standard that expected

<font size="2">z = foo( a[ x ] + b , c ) + d ;</font>

That's neither here nor there; doesn't show one person is right or wrong, just that tastes, perceptions, and experiences vary.
As for the constants: When was Color.WHITE introduced? Before, it was just Color.white.
This seems to have been JDK 1.4.0. Found this bug report:
http://developer.java.sun.com/developer/bugParade/bugs/4407376.html
(Golly, where did that last comment come from?)
Most interesting was the observation that the naming convention for constants is in the JLS (both editions), not just the style doc. [JLS1] [JLS2] So see Paul, you're violating the JLS, which predated your style guide! Actually it's presented there as a recommendation, not a rule, so I suppose you're OK. Maybe.
I'm glad to see that the JLS version does avoid the ambiguity of the style guide. That is, it's intentionally ambiguous in using terms like "should" and "may", rather than being unintentionally vague by using poorly-defined terms.
I note that Josh Bloch uses uppercase in his examples for enumerated types, in Effective Java p. 104-114. Though elsewhere I've seen examples of the new enum construct using lower case. Which is consistent with the use of "may" earlier. Oh well.
Aside from the special cases I've been talking about though, the vast majority of constants in the Java APIs are named with UPPER_CASE. Even if it's not an absolute rule, Java coders should expect to see and use this type of name pretty frequently, simply because they should be making use of standard libraries pretty frequently. IMO of course.
Cheers...
[ October 01, 2003: Message edited by: Jim Yingst ]

[Thomas Paul]

Originally posted by Jim Yingst:
If the Sun style guide had referred to compile-time contstants rather than mere constants, we'd have more to owrk with here.

The problem is that for most programmers it isn't always easy to figure out whether a constant is a compile time constant. So it's best to just stick to the rule that ALL constants follow the same standard.

[paul wheaton]

Originally posted by Thomas Paul:

The problem is that for most programmers it isn't always easy to figure out whether a constant is a compile time constant. So it's best to just stick to the rule that ALL constants follow the same standard.

The way you present this Tom, you make it sound like a fact. Do you have proof about what "most programmers" find "easy to figure out"?
Do you have proof about what is "best"?
I think the point I was attempting to make, and which my attempt must have been a poor one because you didn't address it, was that the developer did not need to know whether it was a constant or not. The developer simply uses the value. Whether it is a constant or not is abstracted (one of the cornerstones of object oriented programming).

[paul wheaton]

As for brace placement: I would guess that I've been professionally involved with about a dozen Java project. In only one project was the K&R brace placement dominant. In ALL of the others, the pascal style brace placement was dominant.
Based on my limited experience, I would estimate that pascal style brace placement is used more often than K&R brace placement. I would even go so far as to suggest that pascal style brace placement is used 65% of the time.

[Thomas Paul]

Originally posted by Paul Wheaton:
Based on my limited experience, I would estimate that pascal style brace placement is used more often than K&R brace placement. I would even go so far as to suggest that pascal style brace placement is used 65% of the time.

I have never worked in a shop that used Pascal style braces. Exceot for my brief tenure working in C#.

[Thomas Paul]

Originally posted by Paul Wheaton:
I think the point I was attempting to make, and which my attempt must have been a poor one because you didn't address it, was that the developer did not need to know whether it was a constant or not. The developer simply uses the value. Whether it is a constant or not is abstracted (one of the cornerstones of object oriented programming).

The problem is that you need to know whether something is a compile time constant. You can't "abstract" it out.
Look at these two classes:

public class A {
    public static final int COMPILE_TIME_CONSTANT = 0;
}
public class B {
   public static void main(String[] args) {
      System.out.println(A.COMPILE_TIME_CONSTANT);
   }
}

Compile and run and it prints 0. Change COMPILE_TIME_CONSTANT to 1. Rerun. It still prints 0. This can be a difficult to diagnose bug if you aren't aware that COMPILE_TIME_CONSTANT is a compile time constant.

[Thomas Paul]

Originally posted by Paul Wheaton:
The way you present this Tom, you make it sound like a fact. Do you have proof about what "most programmers" find "easy to figure out"?
Do you have proof about what is "best"?

I seem to have hit a sore point with you. I don't mean to get you upset. We are talking about something that is a matter of opinion so asking for "proof" is getting a little wierd.
It is never easy using just the API to know if something is a compile time constant. Just because something is final and static does not make it a compile time constant:
public static final long NOT_CTC=System.currentTimeMillis();
How about this:

class A {
    public static final int MAYBE_CTC = getValue();
    
    public static final int getValue() { return 10;}
}

[paul wheaton]

Originally posted by Thomas Paul:

I seem to have hit a sore point with you. I don't mean to get you upset. We are talking about something that is a matter of opinion so asking for "proof" is getting a little wierd.

This may very well be something I'm sensitive about that I should not be sensitive about. It could be something about different cultures or something (east coast vs. west coast?). I have to admit that this isn't the first time I've seen opinion presented as fact. I suppose if enough people do it, I need to adjust rather than contest the truth of it.
I know I would feel pretty weird saying "Most Java programmers use Pascal style brace placement. The Sun style guide is contrary to the industry standard." Such bold statements would certainly help my point. I suppose stupid people might even think that because I stated them as facts, they are facts. I would hope that smart people would challenge such bold statements. But .... maybe this is the way folks exchange opinions in many places. The "IMO", "I think", "Maybe" is all implied.
Personally, I like the idea of proper qualifiers. It seems to help get to the bottom of things quicker. We have our facts. We have our probabilities. We have our possibilities. We have our theories. And we have our opinions.
But I may be alone in thinking this way.
[ October 02, 2003: Message edited by: Paul Wheaton ]

[Thomas Paul]

You really thought that this:
So it's best to just stick to the rule that ALL constants follow the same standard.
was a statement of fact and not opinion?
But if you meant this:
The problem is that for most programmers it isn't always easy to figure out whether a constant is a compile time constant.
then yes that is a statement of fact and I would be willing to bet hard cash that it is true.
Here's my API listing:
static final String TOM_CONSTANT
Is it a compile time constant?
[ October 02, 2003: Message edited by: Thomas Paul ]

[paul wheaton]

Both are stated as facts.
As for "So it's best to just stick to the rule that ALL constants follow the same standard.": I think you are suggesting that because Sun is now attempting to strick to a standard, the rest of us should follow the Sun standard. I don't agree with that. So I guess if it is presented as a fact, I would argue that the statement is false. If it is presented as an opinion, the statement is true (as in, it truly is your opinion).
As for "The problem is that for most programmers it isn't always easy to figure out whether a constant is a compile time constant." Polling the minds of millions of people can be a large task. At least, larger than I'm willing to take on. If this statement is fact, it would appear that you have already completed such polling and the results are in. If such large scale polling were done, I would hope that I would have heard about it. And being a programmer, I would wonder why I didn't get asked. (Maybe programmers were polled alphabetically. And once 85% were polled, it was clear that even if the remaining 15% were polled, there would still be at least a 51% majority, so the rest of the polling was cancelled ... )
But, again, I think the error is mine. In my experience there are some groups where everybody is as picky as I am about stating what is fact and what is hypothesis. And in other groups, stating hypothesis as fact is natural. And there have been times when I have errantly stated hypothesis as fact, and I'm glad when people point it out.
I guess I get confused in the latter group. I find it hard to make a point. It seems like everybody just throws out confilicting "facts" and hopes that when the dust settles there will be progress. Maybe there is a method to it that is simply beyond my comprehension.

[Marilyn de Queiroz]

Originally posted by Thomas Paul:
I disagree with you on the constants. I think it is important that we know which variables are constants because constants are assigned at compile time. If I compile my class and then someone changes the class with the compile time constant in it, I am not going to see that change of the compile time constant. Changing a public variable that is marked as a compile time constant is a violation of the interface contract because it has implications that may make my code fail months from now at recompile time.

If someone changes the class with the compile time constant in it, I would think that they would recompile that class. If someone changes the class to overload a method, I would think that they would recompile that class. If someone changes the class to change the constant to a variable, I would think that they would recompile that class. If someone changes the class ..., I would think that they would recompile that class.

[Marilyn de Queiroz]

Originally posted by Thomas Paul:
So it's best to just stick to the rule that ALL constants follow the same standard.

Or the rule that ALL identifiers follow the same standards.

[Ernest Friedman-Hill]

If someone changes the class with the compile time constant in it, I would think that they would recompile that class.

You may be forgetting that a Java compiler will take static final "compile-time constant" variables and fold their literal values into the code of other classes that they compile. Thus you can change the constant in the class where it's defined and recompile that class, and then other classes that use that constant will be out of synch; they need recompiling, too. That's what Thomas is talking about.

[Jim Yingst]

[MdQ]: If someone changes the class with the compile time constant in it, I would think that they would recompile that class. If someone changes the class to overload a method, I would think that they would recompile that class. If someone changes the class to change the constant to a variable, I would think that they would recompile that class. If someone changes the class ..., I would think that they would recompile that class.
Yes, but Tom's point is that with compile-time constants, that's not enough. You've also got to recompile any other classes which used that constant, because the fact that it was a compile-time constant means that the compiler has already computed the actual value and stuck it into those other classes. So If the value has changed, they need to be recomopiled.
Now personally I've never had much need to identify whether something was a compile-time constant or not, even though I have little trouble doing so, because there are a number of other problems that can arise if you recompile just one class in a project without recompiling the whole project. In fact recompiling isn't quite enough; before I had an IDE that took care of this for me, I would write a batch file for compiling any project I was working on, and step 1 was usually to delete all class files. If you change the name of a class, but some of your code still refers to the old class, it may still compile OK because the system is just referencing the old class file which is still there, even though the .java file that generated it, no longer exists (i.e. it's been renamed). So I try to do clean builds fairly religiously. Nowadays Eclipse does this well enough that I usually don't worry about it, but when I use Ant step 1 is, again, delete the old class files. (I keep having to tell eclipse to refresh its view after this; maybe there's a better way.) So personally I don't really have an issue with knowing if a variable is a compile-time constant or not, but I see where Tom is coming from.
Actually what I do care about, more often, is whether a given field represents mutable data or not. For this, I need it to be final, and the type must be primitive, or an immutable type. If that's the case, I can use it without synchonization in a multi-threaded environment, which is helpful to know. And unlike the problems of hte previous paragraph, this is not easily solved by an IDE or script, so I find myself wishing for better mechanisms for knowing that something is immutable. Hence, my interest in exactly what a "constant" really is.
Unfortunately, I agree with Tom that, even if some programmers can correctly tell whether something is a compile-tme constant, or immutable, I wouldn't really trust most of them to do so reliably. So regardless of the exact definition or standard used, the most I can hope for from seeing an UPPERCASE_NAME is that it signals that a given field is probably a compile-time constant, and probably immutable, but if & when I really care I'd better check for myself. It would be nice, IMO, if there were an "immutable" keyword and the compiler could check this for me, but there isn't.
So, anyway, I still prefer UPPERCASE_FOR_CONSTANTS, but mostly just for visual consistency with existing libraries. The heads-up that something may be a particular kind of constant is nice, but not to be trusted fully if it really matters.
All IMO of course. A conversation like this, I tend to assume that there are implied IMOs among everyone's comments, but it's helpful to state so explicitly now and then.
Cheers...
[ October 02, 2003: Message edited by: Jim Yingst ]

[Thomas Paul]

Originally posted by Marilyn de Queiroz:
If someone changes the class with the compile time constant in it, I would think that they would recompile that class.

Which, of course, doesn't help the person using that compile time constant in their class. Since it is a compile time constant they would need to re-compile their class as well in order to get the change. But thanks, Marilyn, I think you proved my point.
[ October 02, 2003: Message edited by: Thomas Paul ]

[Jim Yingst]

Or the rule that ALL identifiers follow the same standards.
All identifiers for fields and variables, but not types, and unless they're part of standard libraries and/or are following the JLS? Yeah, Sun could have simplified this when they first designed the language, but they didn't, and revising it now seems like wishful thinking to me. Sure, Sun's own compliance hasn't been perfect, but it's gotten substantially better over the years...
[ October 02, 2003: Message edited by: Jim Yingst ]

[Thomas Paul]

Paul is weirding me out so I'm not going to respond here anymore. Carry on without me.

[jason adam]

Woo, what a topic.
Thought I would throw in my two cents about having students learn Sun's way of doing things over having students learn from another Style Guide (like our little Cattle Drivers we've been torturing).
Being an ex-teacher, I know from experience that teaching someone how to use something in a general sense is far more effecient later than teaching someone the specifics and then going back and trying to apply that generally. They want to revert back to the way they first learned, and have a harder time adapting.
With the Cattle Drive, we teach the students how to look at a Style Guide, how to follow one, and how to write code that abides by those rules. I don't think once during my nitpicks as a student, nor while nitpicking assignments myself, was the JR style guide preached as the way to do things in the "real world", or better than other style guides. We instead focus on enabling the students to read style guides for themselves and get them used to following the standards that others set down.
So whether we used Sun's style guide, JR's style guide, Billy Bob's style guide from up the road doesn't matter. As long as the students learn that sometimes they have to forget the way they want to do things and instead do things the way some old fart up the corporate ladder said to do things, then I'm happy.
I've had a couple of students fight me on some of my comments about the need for them to change their code to fit with our style guide(though "fight" may be a bit strong of a word) because "that's not how I'm used to doing things". Well ya know what, tough. Life doesn't always conform to one standard, so you have to learn to adapt. Could you imagine going up to your boss and saying that you refuse to change your code and you think that the corporate style guide (and therefore everyone elses code that complies with it) should change to fit yours?
To truly get students to learn, perhaps we should introduce different style guides for different assignments, but that would probably put more work on the nitpickers.

[Marilyn de Queiroz]

Originally posted by Jim Yingst:
Tom's point is that with compile-time constants, that's not enough. You've also got to recompile any other classes which used that constant.

Originally posted by Ernest Friedman-Hill:
You may be forgetting that a Java compiler will take static final "compile-time constant" variables and fold their literal values into the code of other classes that they compile.

Yes, I did know that. I guess that, like Jim, I (almost) always recompile the whole project, so that fact had slipped to the back of my memory. Thanks for reminding me.

[Bert Bates]

Wow!
I never looked at the JavaRanch style guide before...
One point that I think we ought to consider is that people taking the SCJD certification had better darn well use Sun's style guide. It's not uncommon for an assessor to deduct points for non-Sun style. Given that certification is a significant part of JavaRanch, I'd vote to reconsider the JavaRanch recommendation. (Oh, and I have to agree with Jim that compactness is a HUGE virtue )

[Marilyn de Queiroz]

We've had this discussion with Kathy already, Bert. I'll find it and post a link here shortly.

The point is that the student/employee must follow the style guide that is required by the instructor/employer. If you are attempting to get a certificate from Sun, you follow Sun's Style Guide. If you are a student in the JavaRanch Cattle Drive, you follow JavaRanch's Style Guide.

[Marilyn de Queiroz]

Ok. No link. The discussion was in the MO forum. Please see it there.

[Matthew Phillips]

Originally posted by jason adam:
To truly get students to learn, perhaps we should introduce different style guides for different assignments, but that would probably put more work on the nitpickers.

This is a fantastic idea, although it does make it difficult for the nitpickers. Would it be easier if it alternated by "schools" and have each nitpicker work only with that "school."