Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Two questions on Java Programming Style Guide  RSS feed

 
Jimi Svedenholm
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have two questions regarding your Java Programming Style Guide (http://www.javaranch.com/styleLong.jsp)

1. In 3.1.1 you advice against using "do... while", and suggest using a regular while loop instead. But shouldn't you also point out that there is a big difference between the two? "do... while" always executes the code in the block at least once, while the regular while loop might not.

2. In 3.4 you say "All fields must be private, except for some constants." Are you saying that if I write a class that is meant to be extended, I should use protected get and set methods instead of making the field itself protected? Why? The maker of the CMS we use (in a project I'm in) has given us many options to use our own extensions of their classes and this is very nice. But in some of these cases they have private fields with no get/set methods so we can't access them the way we want (and need, actually). I really can't see the point of this. By making a variable protected they would hand over the responsibility to us, and that is fine by me.

Regards
/Jimi
 
fred rosenberger
lowercase baba
Bartender
Posts: 12529
48
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"jimih",

You have been asked before to update your screen name to meet our guideline. Please read the policy here, and follow the link found there to update your screen name. This is a mandatory policy here.

Your prompt attention in this matter is greatly appreciated.

fbr
 
Jimi Svedenholm
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Fred,

Yes I know about this policy, and I have changed my display name now. I thought I already had done this with this account (but that might have been with another account, registered to some email that I have forgotten). So I didn't check that setting before posting. I'm sorry about that.

/Jimi
 
fred rosenberger
lowercase baba
Bartender
Posts: 12529
48
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks.

I didn't come up with the coding standard, but here's my thoughs...

personally, I don't see a big difference between the two loops. one is "zero or more", the other is "one or more". the latter is sort of like a sub-set of the former. Remember, the purpose of the style guide is not to teach you about the differences in Java, but to establish the "correct" way to do them.

and by "correct", i mean within that framework. going somewhere else, they'd have a different "correct" way.

The maker of the CMS we use (in a project I'm in)

well, i'd argue that that is outside the scope of the styleguide here. the styleguide here is what is required for the cattledrive projects. You are free to use it elsewhere, or not. if you have some styleguide you use for your project, you should follow it.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The JavaRanch style guide mainly reflects the personal preferences of one individual. The most important purpose of the JR style guide is to give people practice in following one; very often this will be part of the fledgling programmer's job, and they need to be used to the idea of writing their code according to a guide, without consideration of whether the guide is "right" or not.
 
Marilyn de Queiroz
Sheriff
Posts: 9080
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. ... But shouldn't you also point out that there is a big difference between the two?

The style guide is not attempting to teach java to the reader but to set some guidelines for the way it is used.

2. In 3.4 you say "All fields must be private, except for some constants." Are you saying that if I write a class that is meant to be extended, I should use protected get and set methods instead of making the field itself protected? Why?

I think you could use public get and set methods. Making a field protected may be opening a can of worms, especially when multi-threading is involved. I have seen some hard to find bugs introduced by the use of protected fields.

If you really need access to those fields, I would contact the developers of the CMS to ask them to add getters (and setters).
 
Marilyn de Queiroz
Sheriff
Posts: 9080
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"The JavaRanch style guide mainly reflects the personal preferences of one individual."

I think that's a strong statement. I think the statements in the JavaRanch style guide are the opinion of more than one individual of the way java should be written. I think that many of the statements, if not most, are supported by a good percentage of java developers.
 
Jimi Svedenholm
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you could use public get and set methods. Making a field protected may be opening a can of worms, especially when multi-threading is involved. I have seen some hard to find bugs introduced by the use of protected fields.

How do you mean that public get and set methods would be *safer*? I'm talking about private fields like hashtables and stuff here, and protected get/set methods for the actuall hashtable (not the get/set methods's using key and value).

If you really need access to those fields, I would contact the developers of the CMS to ask them to add getters (and setters).

Well, most of these occasions I don't like waiting weeks or months for a fix like this. And in general I think that if so many classes are meant to be extended if needed, then the extending class should be able to influence main functionality in the extended class.

But I agree with you on one thing... the risk of multithreading bugs. But the way I see it, you most likely only know about these protected fields if
you have read some API documentation about the class, that specifies proteced fields or you have read the accual source code (or decompiled code). In the first case, I think it's the responsebillity of the writer of that documentation to warn about potential multi-threading issues, and in the second case it is your own responsibillity to understand the code enough to be able to detect any such potential issues. So either way, the person writing the extending class should be held responsible for new bugs introduced.

In general I think that a person writing a class that is likely to be extended by someone else should not have to take "full responsibillity".
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by jimih:
How do you mean that public get and set methods would be *safer*? I'm talking about private fields like hashtables and stuff here, and protected get/set methods for the actuall hashtable (not the get/set methods's using key and value).


The principle that gets violated by making fields less-than-private is that classes (and their interfaces) should be defined by their behavior, not by data.

The concrete disadvantage in this specific case is that you loose a lot of flexibility for changing the way the class fulfills its responsibility, including

- the ability to do something every time the value changes, such as notifying listeners, calculating a derived value etc.

- the ability to store the data in a different format, i.e. store a duration in seconds instead of hours

- the ability to lazily calculate the data the first time it is requested

- the ability to store the data somewhere else and to just delegate in the getters and setters

- implementing design patterns such as Proxy/Decorator

There are probably more, but these are the ones that came to mind instantly, and in my opinion would very well warrant only using private fields (unless your classes are really mere data holders, with no behavior at all).
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!