• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Two questions on Java Programming Style Guide

 
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
 
lowercase baba
Posts: 12773
51
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
Posts: 12773
51
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.
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • 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.
 
Sheriff
Posts: 9099
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: 9099
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".
 
author
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).
 
I didn't like the taste of tongue and it didn't like the taste of me. I will now try this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!