• 0

[JAVA] naming conventions


Question

Sun's Java style rules specify that accessors should follow the getX/setX pattern, and most Java API mathods follow this...

except for some very common exceptions such as:

String length()

enum name() [NB new to 1.5, so not a legacy!]

ArrayList size()

etc

It seems that there is another pattern operating here: methods that access a private field which will never be set from outside the class are simply named after the field.

Has anyone seen this documented? Is there some other explanation?

  • Sad 1
Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 0

To me yes, they did violate it.... what your saying about private get variables only - meh I havent seen that convention any where.

They should have (by convention) had getLength(), getSize(), getName() ..... I would stick to gets and sets as a developer it makes it easier to see what you can set and get in drop code complete lists. I think it is also a lot cleaner too.

Link to comment
Share on other sites

  • 0

Huh? length for a String is a simple invariant value (Strings are immutable), ditto name() for an enum. In what way "beyond simple accessors?

Link to comment
Share on other sites

  • 0

The part that answers your question.

It's there since the begining. With the exception of enum's name() that's probably part of the fourth version, which I haven't read.

Link to comment
Share on other sites

  • 0

Yes, I'm very familiar with the code conventions in the JLS. Those are the standards to which I was referring. Interestingly, if you go back to the original Sun coding standards, you won't find the exception for length(). It appears that length() crept into the String API under the radar, and they retrofitted the standards to allow it later. In any case, the enum methods, new to version 1.5 clearly violate the JLS standards, so my question remains unanswered.

I'm still curious to know what you meant by "beyond simple accessors"

Link to comment
Share on other sites

  • 0
Interestingly, if you go back to the original Sun coding standards, you won't find the exception for length().

length() is defined since the first Java Language Specification (page 108, first edition, 1996, right next to me).

I'm still curious to know what you meant by "beyond simple accessors"

You don't need to implicitly get those variables, since you can't implicitly change their state (other than changing the object and ****). That's why get isn't necessary.

Most people think this is another of Java's gotchas. I don't agree.

Link to comment
Share on other sites

  • 0
You don't need to implicitly get those variables, since you can't implicitly change their state...

Sorry if I'm being slow here. Did you really mean implicitly rather than explicitly? Either way, it sounds like what I hypothesized in my OP, which is that this idiom is used for variables that can only be got, never set. Despite the enum example I've never seen any standards documentation to allow name() or ordinal(), despite the fact that 1.5 was the subject of extensive and rigourpous code reviews. If you know of one I'd be really glad to see it.

As for the "original" Sun coding standards - here http://java.sun.com/docs/codeconv/html/Cod...s.doc8.html#367 is a 1999 update of a 1995 doc, stating explicitly "Methods should be verbs..." - but I'm happy not to turn this particular issue into a major debate 'cos I'm more interested in the modern exceptions to the modern standards.

James.

Link to comment
Share on other sites

  • 0

You're not being slow. It's a combination of events that are pretty cool: {English is not my first language), and I was doing first order logic exercises with implications, and I so douchebag that often don't read first posts, like yours in this thread.

So if "methods that access a private field which will never be set from outside the class are simply named after the field" is okay?

In my opinion, yes. But if you ask any one of my teachers, they'll say to read the code conventions and use getters/setters for everything, because it makes "sense". I say that the code conventions aren't exactly mandatory guidelines.

I really have no idea on what's going on with enum, because still I haven't touched this new feature.

Let me put it this way: use the code conventions of the target of your code.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.