URL and Url?

[Aquila Deus]

Why does Sun choose the class name "URL" for URL, but use "Jsp" for
JSP? If I have an abbrev to name now, which one (upper or capital)
should I use?

 

[Andrew Thompson]

Why does Sun choose the class name "URL" for URL, but use "Jsp" for
JSP?

Sh*t happens in the real world.

Sun has not been consistent with their own nomenclature and
recommendations on a number of occasions, basically because..
a) some sources were written prior to the convention, but more commonly
b) some Sun programmers were either
- unaware of the Sun standards/convention
- did not give a toss in any case, and went their own way.

There are probably also some (occasional) other good reasons where
there might exist an oddity (E.G. a constant derived from a standard
external to Java/Sun).

 

[Chris Smith]

Why does Sun choose the class name "URL" for URL, but use "Jsp" for
JSP? If I have an abbrev to name now, which one (upper or capital)
should I use?

The Sun naming conventions, which are adopted almost universally in
Java, direct you to leave acronyms in all caps. You should consider
JspWriter and such classes to be an anomaly, and don't follow their
lead.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[anonymous]

Why does Sun choose the class name "URL" for URL, but use "Jsp" for
JSP? If I have an abbrev to name now, which one (upper or capital)
should I use?

Probably the same reason someone came up with length() instead of
getLength() or seize() instead of getSize() for some classes/objects,
Oracle came up with untitlet1.jsp as the default JSP name in JDeveloper
(might have chosen Untitled1.jsp).
Someone didn't think ;-)
Sometimes these questions require knowledge beyond Life itself.

 

[Aquila Deus]

The Sun naming conventions, which are adopted almost universally in
Java, direct you to leave acronyms in all caps. You should consider
JspWriter and such classes to be an anomaly, and don't follow their
lead.

I see. But what if there is some name like CORBA-ORB-IO-Exception?
CORBAORBIOException is unreadable!

 

[Aquila Deus]

The Sun naming conventions, which are adopted almost universally in
Java, direct you to leave acronyms in all caps. You should consider
JspWriter and such classes to be an anomaly, and don't follow their
lead.

I see. But what if there is some name like CORBA-ORB-IO-Exception?
CORBAORBIOException is unreadable!

 

[Filip Larsen]

Chris Smith wrote

The Sun naming conventions, which are adopted almost universally in
Java, direct you to leave acronyms in all caps. You should consider
JspWriter and such classes to be an anomaly, and don't follow their
lead.

Where do you read that exactly? The Sun convention is very brief on
acronyms it seems.

Looking at the Java standard class names there are some deviation from
the convention you mention, for instance: JarInputStream,
ZipInputStream, MidiFileReader, LdapContext, HttpURLConnection, and a
large number of class names ending in Spi. The HttpURLConnection is
interesting since it "solves" the problem with multiple acronyms in one
name.

Personally I have no trouble using names like, say,
XmlElement.readXmlFile which I find more readable than
XMLElement.readXMLFile.


Regards,

 

[Chris Smith]

Where do you read that exactly? The Sun convention is very brief on
acronyms it seems.

Oops, you're right. I must have been confusing something that I read
elsewhere. Nevertheless, I'd still go for all-caps in acronyms when
possible. Obviously, if several acronyms butt together, that's a
problem to be solved, potentially by writing one in mixed case.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[thufir]

Filip Larsen wrote:
[..]

Personally I have no trouble using names like, say,
XmlElement.readXmlFile which I find more readable than
XMLElement.readXMLFile.

[..]

how about XMLelement.readXMLfile ?

 

[Jacob]

Why does Sun choose the class name "URL" for URL, but use "Jsp" for
JSP? If I have an abbrev to name now, which one (upper or capital)
should I use?

Sun actually lacks a proper naming standard.

Consider instead these guidelines and guideline #7 in
particular: http://geosoft.no/development/javastyle.html

 

[Antti S. Brax]

Consider instead these guidelines and guideline #7 in
particular: http://geosoft.no/development/javastyle.html

This is good.

But I think more important is that when writing acronyms that
way it removes one special case from your naming convention.

One less things to worry about when writing code.

 

[Real Gagnon]

Sun actually lacks a proper naming standard.

Consider instead these guidelines and guideline #7 in
particular: http://geosoft.no/development/javastyle.html

Another reference is
https://jjguidelines.dev.java.net/

especially
https://jjguidelines.dev.java.net/book/html/apa.html

Bye.

 

[Antti S. Brax]

This is good.

But I think more important is that when writing acronyms that
way it removes one special case from your naming convention.

Now that I read it more carefully I must mention one thing. In
number 14 you recommend using "is" and "has" prefix for boolean
type accessors. The example "hasLicense" points an obvious
problem: what is the variable you are accessing?

If the variable is "license" then it is obviously badly named
as a variable with that name should refer to the actual license.
If the variable is "hasLicense" then you're breaking your own
naming convention by not having a prefix.

You also try to reason the rule with a faulty example. A method
named "getStatus" which returns a boolean value fits just as
well as "isStatus" does.


I like to use the "no exceptions" naming rule with boolean
variables too: all accessors are prefixed with "get" and "set".
There are no exceptions.

"getHasLicense" is not that much longer to write and you can
still see from the method name that you are accessing a boolean
variable. Same goes with "getCanEvaluate" and "getShouldAbort".

You also weaken your own rule by failing to mention the "is"
and "has" (and "can" and "should") prefixes in number 23.

IMHO




And exceptions are part of the main design of a program (but that
is out of scope for this discussion).

 

[Jacob]

Now that I read it more carefully I must mention one thing. In
number 14 you recommend using "is" and "has" prefix for boolean
type accessors. The example "hasLicense" points an obvious
problem: what is the variable you are accessing?

If the variable is "license" then it is obviously badly named
as a variable with that name should refer to the actual license.
If the variable is "hasLicense" then you're breaking your own
naming convention by not having a prefix.

First, the general rule is to use "is" prefix for boolean queryies.
This fits 99.9% of the time. The counter example may be badly choosen,
but still points to the fact that using "is" sometimes makes the term
artifitial.

A licensed software module will (depending on impelementation) start and
then request a license. If it doesn't get one it may continue to run but
with limited functionality. It may be appropriate for a sub component to
ask if it "has license" in order to complete its tasks. getLicense() is
a different query, and same with isLicensed(). isLicenseAvailable() can
be used but then I'd prefer hasLicense(). Opinions are welcomed!

Note the Java API is very inconsistent on this point:

boolean Calendar.before()
boolean Calendar.after()
boolean Component.hasFocus()
boolean Component.requestFocusInWindow()
boolean Vector.contains()
boolean Collection.add()
boolean String.matches()
boolean String.startsWith()
boolean Comparable.equals()

to give a few examples.

You also try to reason the rule with a faulty example. A method
named "getStatus" which returns a boolean value fits just as
well as "isStatus" does.

When naming boolean variables, find a term that fits with "is"-prefix,
like "visible" or "open" etc. "status" fails this test and is thus a
bad name for a boolean setting.

I like to use the "no exceptions" naming rule with boolean
variables too: all accessors are prefixed with "get" and "set".
There are no exceptions.

"getHasLicense" is not that much longer to write and you can
still see from the method name that you are accessing a boolean
variable. Same goes with "getCanEvaluate" and "getShouldAbort".

I don't find these terms as readable as the originals. Also, what you actually
access in the back-end is irrelevant. This is an API, and the query is boolean.

You also weaken your own rule by failing to mention the "is"
and "has" (and "can" and "should") prefixes in number 23.

The "is" prefix has to do with boolean names. Rule #23 has to do with naming
and term usage in general. There is no connection between the two.

And exceptions are part of the main design of a program (but that
is out of scope for this discussion).

Depends on the definition of "exceptional behaviour". I probably agree with
you and should tune the rationale for Rule #27. It doesn't change the
naming convention though.

 

[Tony Morris]

The Sun naming conventions, which are adopted almost universally in
No it doesn't.

<quote section="9">
Class names should be nouns, in mixed case
with the first letter of each internal word capitalized.
Try to keep your class names simple
and descriptive. Use whole words-avoid
acronyms and abbreviations (unless the abbreviation
is much more widely used than the
long form, such as URL or HTML).
</quote>

 

[Antti S. Brax]

Note the Java API is very inconsistent on this point:

boolean Calendar.before()
boolean Calendar.after()
boolean Component.hasFocus()
boolean Component.requestFocusInWindow()
boolean Vector.contains()
boolean Collection.add()
boolean String.matches()
boolean String.startsWith()
boolean Comparable.equals()

I thought we were talking about naming acessors. Here hasFocus
is the only accessor.

Java API is very inconsistent in naming. That was stated in the
eginning of this discussion. It's a good example about what
happens when there are no naming conventions.

When naming boolean variables, find a term that fits with "is"-prefix,
like "visible" or "open" etc. "status" fails this test and is thus a
bad name for a boolean setting.

I meant that method "getStatus" that returns a boolean is just
as bad name and should ring the same alarm bell.

I don't find these terms as readable as the originals. Also, what you actually
access in the back-end is irrelevant. This is an API, and the query is boolean.

Readability is a matter of an opinion and custom. You may also
find my way of indentation less readable but that is only because
you are used to your own way. So your argument is pretty much
useless ("holy wars" are started with arguments like that). I
have changed my way of indentation many times over the years and
have become accustomed to each way very quickly.

Do you have an argument against the "no exceptions" rule?

The "is" prefix has to do with boolean names. Rule #23 has to do with naming
and term usage in general. There is no connection between the two.

I see a connection: #14 is an exception to #23. Exceptions in
naming rules are bad, because people do not remember them.

Depends on the definition of "exceptional behaviour". I probably agree with
you and should tune the rationale for Rule #27. It doesn't change the
naming convention though.

Correct. That's why it is out of scope for this discussion.