RFC - Coding Conventions

[Barry Gaunt]

I have just read one of Kathy Sierra's posts here.
Would it not make sense for the Cattle Drive to go along or become compatible with Sun's coding conventions? It would help those moving on later to SCJD.
-Barry

[Peter Gragert]

Do you mean the coding conventions of Sun:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html ?
[ October 18, 2002: Message edited by: Peter Gragert ]

[Matthew Phillips]

One of the main reasons that I think the Cattle Drive won't do that is because the style guide teaches a lesson. Anywhere you go to work is going to have a style guide. It is important to learn to code in a style that is forced upon you because it will happen.
One of the other reasons is that it seems most people find the brace style more readable. At least that is the impression I received from the few discussions I have seen.

[Matthew Phillips]

Originally posted by Marilyn de Queiroz:

Paul wrote the the Style Guide. One of the things we're trying to teach students of the Cattle Drive is that each company you work for will probably have a style guide. You should be flexible enough to follow their style guide without complaint. If the student is doing an assignment for Sun, they should follow Sun's style guide. If they are doing an assignment for the Cattle Drive, they should follow the JR style guide.

Marilyn puts it so much better than I did.

[Barry Gaunt]

I'll go along with that, it's more a convenience issue in having use two styles at the same time.
In fact I prefer some of CD's conventions having used them in a former life.

[paul wheaton]

My impression is that a lot of people do not care for the sun style guide.
Naturally, I think my style guide is "da bomb". Of course, there are people that think my style guide is stupid.
The two biggest points that come to mind are brace placement and using uppercase for constants.
The sun guide promotes the "K&R" style of brace placement and I push the "Pascal" style. It seems to me that about 70% of the java developers use the pascal style.
I think that forcing constants to all upper case is akin to hungarian notation. Whether the value is final or not should be abstracted. As a developer, should we care how it is implemented? It seems that we should leave the "final" keyword as a potential optimization without having to go through all code that uses it and changing its capitalization just because we changed our mind about optimizing vs. flexibility.

[Michael Matola]

PW> I think that forcing constants to all upper case is akin to hungarian notation. Whether the value is final or not should be abstracted. As a developer, should we care how it is implemented?
Would you go so far as to not even expose the fact that it's a constant? I mean, declaring it private and providing a public accessor method.

[paul wheaton]

It depends
Of course, there are the things that I do, and there are the things that the document would require everybody in a group to do (if they choose to adopt a standard).
My favorite example is for writing a VT100 terminal emulator. The screen width is 80 characters. So you might have a class Terminal with the attribute
private static final int screenWidth = 80;
Suppose another class needs access to that tidbit of info. The style guide says that it has to be private. When programming to that standard, there is no choice. I am tempted to change it to public or maybe protected.
The down side is clear: should the time come for my Terminal class to support VT220, the width of 80 can no longer be final. A getter is more appropriate. On the other hand, trying to design or program with a crystal ball is generally a bad idea - you can easily increase your workload by a factor of ten if you keep your eye on what could be. Better to adopt good habits, focus on the present and think very little of the future.
Maybe a better question for this case is: should anything outside of this class be concerned with the width of my terminal object?