Java Code Convention Guidelines question...

[New]

Hello.

I just saw a code convention guideline for java that confuses me.

It's from SUN, so I'm sure it's not a typo:

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

10.2 Referring to Class Variables and Methods

Avoid using an object to access a class (static) variable or method.
Use a class name instead. For example:
classMethod(); //OK
AClass.classMethod(); //OK
anObject.classMethod(); //AVOID!

My questions:
What's the point of having variable names if you can't use them???

Thank you, new

 

[Brian Palmer]

10.2 Referring to Class Variables and Methods

Avoid using an object to access a class (static) variable or method.
Use a class name instead. For example:
classMethod(); //OK
AClass.classMethod(); //OK
anObject.classMethod(); //AVOID!

My questions:
What's the point of having variable names if you can't use them???

You can; you just should specify the class.
class MyClass {
int i; // instance variable
static int counter; // class (static) variable
}

and I have MyClass myc = new MyClass(); which I want to access,
I should access i as myc.i, and counter as MyClass.counter.

You could always say 'myc.counter', but that is misleading. (In
particular, it can be misleading in the presence of inheritance.
class Base { static int VALUE = 1; }
class Child extends Base { static int VALUE=2; }

.... static void main(String[] args) { Base b = new Child();
System.out.println(b.VALUE); }
Do you expect it to print 1 or 2?

 

[Roedy Green]

anObject.classMethod(); //AVOID!

My questions:
What's the point of having variable names if you can't use them???

You have to use this syntax when the method is an instance method.
However, they suggest using the Class.method syntax for class methods.

 

[Lee Weiner]

Hello.

I just saw a code convention guideline for java that confuses me.

It's from SUN, so I'm sure it's not a typo:

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

10.2 Referring to Class Variables and Methods

Avoid using an object to access a class (static) variable or method.
Use a class name instead. For example:
classMethod(); //OK
AClass.classMethod(); //OK
anObject.classMethod(); //AVOID!

My questions:
What's the point of having variable names if you can't use them???

The paragraph is referring to static methods and variables only. Since only
static members can be accessed from the name of the class, the second line of
code points out to any reader that classMethod() MUST be static. The third
line is ambiguous. A reader doesn't know (from that line) whether
classMethod() is static or not. Non-static members must be accessed from an
object variable.

Lee Weiner
lee AT leeweiner DOT org

 

[Chris Smith]

The paragraph is referring to static methods and variables only. Since only
static members can be accessed from the name of the class, the second line of
code points out to any reader that classMethod() MUST be static. The third
line is ambiguous. A reader doesn't know (from that line) whether
classMethod() is static or not. Non-static members must be accessed from an
object variable.

I'd choose stronger language. Specifically, I'd say that the third form
strongly implies that classMethod() is an instance method. If it's a
static method, the third form is dangerously misleading. The fact that
the form is allowed for static methods doesn't change the fact that it
just plain looks like an instance method invocation.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jezuch]

U¿ytkownik New napisa³:

classMethod(); //OK
AClass.classMethod(); //OK

So classMethod is static, now try this:

AClass x=null;
x.classMethod();

or even

((AClass)null).classMethod();

Isn't that beautifully confusing?
--
Ecce Jezuch
"Feeling paranoid, true enemy or false friend
Anxiety's attacking me, my air is getting thin
Feeling claustrophobic like the walls are closing in
Blood stains on my hands and I don't know where I've been"
- D. Mustaine

 

[rkm]

I'd choose stronger language. Specifically, I'd say that the third form
strongly implies that classMethod() is an instance method. If it's a
static method, the third form is dangerously misleading. The fact that
the form is allowed for static methods doesn't change the fact that it
just plain looks like an instance method invocation.

"dangerously misleading"?

how so? how is it dangerous? Aren't most all of you being
more pedantic than anything? First of all, I'm pretty sure
you cannot write an instance method that overrides a static
method of the same signature (but maybe it's just my
compiler that cares), so there is no danger of accidentally
invoking an instance method where you intended to
invoke a class method. Second of all, should code really be
written that depends on knowing the difference between
whether you're invoking an instance or class method? Should
your algorithms be that brittle? If you have a better
argument than "sun said so" or "that's how it's done in
smalltalk", etc., I'd like to hear it.

Rick

 

[Chris Smith]

"dangerously misleading"?

Yep.

how so? how is it dangerous? Aren't most all of you being
more pedantic than anything? First of all, I'm pretty sure
you cannot write an instance method that overrides a static
method of the same signature (but maybe it's just my
compiler that cares), so there is no danger of accidentally
invoking an instance method where you intended to
invoke a class method.

That's not the issue. The issue is invoking a static method while
thinking that it is (and therefore expecting it to act like) an instance
method. Since the two behave in completely different ways, this could
add bugs to code very easily.

Second of all, should code really be
written that depends on knowing the difference between
whether you're invoking an instance or class method?

Yes. Why wouldn't your code know the difference? It's not as if this
is an implementation detail. It's a fundamental question about what you
are doing! If I look at code and can't tell whether it's invoking a
static or an instance method, that's a serious problem!

Should your algorithms be that brittle?

Not sure what you mean. Since the two are completely different things,
I can't really imagine a situation where I'd actually choose between the
two. Certainly code can't be written to just work in the context of
just any arbitrary change... I could ask you "are your algorithms so
brittle that if I change the value of some constants they would fail to
work?", and you'd probably be just about as much at a loss for how to
answer as I am right now.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[rkm]

Yep.

Yep isn't good enough. You need to provide an example.

That's not the issue. The issue is invoking a static method while
thinking that it is (and therefore expecting it to act like) an instance
method. Since the two behave in completely different ways, this could
add bugs to code very easily.

Again, show an example.

Yes. Why wouldn't your code know the difference? It's not as if this
is an implementation detail. It's a fundamental question about what you
are doing! If I look at code and can't tell whether it's invoking a
static or an instance method, that's a serious problem!

How is it a problem? An example please!

Not sure what you mean. Since the two are completely different things,
I can't really imagine a situation where I'd actually choose between the
two. Certainly code can't be written to just work in the context of
just any arbitrary change... I could ask you "are your algorithms so
brittle that if I change the value of some constants they would fail to
work?", and you'd probably be just about as much at a loss for how to
answer as I am right now.

Let's not confuse things by extending the argument to "any
arbitrary change". No-one said that.

It all sounds nice, but can you show a real example that
illustrates what you're saying?

Rick

 

[Chris Smith]

Again, show an example.

Okay. I fixed a bug about three or four months ago in which someone
called Thread.sleep using an instance reference, and expected it to put
a different thread to sleep. See? The instance method syntax caused
confusion, by implying that the method "sleep" acted on a specific other
instance, when it really doesn't.

I realize that's a little bit different from our conversation, which is
about whether a developer should intentionally pretend to act on some
specific object when they really aren't. Doing so intentionally is so
strange and twisted, though, that I can't possibly think of any sort of
realistic example of someone doing so; so I'm resorting to an example of
accidentally doing so to show how confusing it is.

Let's not confuse things by extending the argument to "any
arbitrary change". No-one said that.

Right. I'm *trying* to prompt you to tell me why you think that
instance and static methods ought to be interchangable... but you're not
taking the hint. So why is it?

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[rkm]

Okay. I fixed a bug about three or four months ago in which someone
called Thread.sleep using an instance reference, and expected it to put
a different thread to sleep. See? The instance method syntax caused
confusion, by implying that the method "sleep" acted on a specific other
instance, when it really doesn't.

This is a good example to prove my point. Here you have a
static method, Thread.sleep, that operates on a specific
thread instance (the current thread). There is nothing
wrong with that since it's fully documented to work that
way. However, the coder you mentioned fell under the spell
of your recommended coding convention, didn't bother to read
the documentation, and assumed calling
someOtherThreadInstance.sleep would work. The coding
convention led to sloppy thinking and a bug, which, as you
put it, could be dangerous.

You didn't say how you coded your fix, but if you just used
a call like Thread.sleep, then you weren't following your
recommended coding convention either. To do so, you would
have to code something like
Thread thisThread = Thread.currentThread();
thisThread.sleep(...);

But most wouldn't bother with that, they would just
call Thread.sleep(...);

Right. I'm *trying* to prompt you to tell me why you think that
instance and static methods ought to be interchangable... but you're not
taking the hint. So why is it?

I just don't believe I should have to understand how a class
and its instances are implemented and what their inheritance
hierarchy is in order to follow this coding convention. I
don't know how fully you intend to go with it, but if
there's some class inheritance hierarchy like A.B.C.D
and I have an instance of D called d, and I want to invoke
some static method that happens to be defined up in B, are
you suggesting I code B.methodB(), and then for some method
in A, A.methodA(), and for C, C.methodC()? So I should
encode the class hierarchy in all my calls to static methods
(after I first research it all to see what's static and what
isn't) ?? I can tell you right now I ain't doin' that. And
if you say, no, I can just use D.methodB(), then I say
that's no better than d.methodB().

Another reason I might not follow the guideline is when the
class name happens to be 38 characters long, one of which I
saw yesterday. If I happened to need to invoke one of its
static methods more than once in my code and I didn't have
an instance handy, I would probably make an instance of that
for the sole purpose of shortening the name down, and I
would call all its static methods thru that instance.

You say that's twisted, but I say it makes the code more
readable.

Rick

 

[Chris Smith]

This is a good example to prove my point.

No not really...

Here you have a
static method, Thread.sleep, that operates on a specific
thread instance (the current thread). There is nothing
wrong with that since it's fully documented to work that
way. However, the coder you mentioned fell under the spell
of your recommended coding convention, didn't bother to read
the documentation, and assumed calling
someOtherThreadInstance.sleep would work.

Okay, hold on a sec. I'm trying to say that Thread.sleep should be
called as "Thread.sleep(100)". You're trying to say that it's okay to
call it as "Thread.currentThread().sleep(100)". Now, consistently
seeing which of those two makes it easier to mistakenly assume that
"otherThread.sleep(100)" is also valid?

Granted, neither convention completely solves this problem by itself,
simply because of the lack of compiler checks. However, at least if you
call static methods with the normal static method call syntax, it takes
a violation of the coding convention to produce such a bug. Thank
goodness, then, that I can set Eclipse to issue a warning (or even an
error, if I wanted) when the convention is violated. Good luck doing
the same!

The coding
convention led to sloppy thinking and a bug, which, as you
put it, could be dangerous.

I think, rather, that sloppy thinking led to a violation of the coding
convention -- and a bug. The bug was easier to find because when I got
to the right part of the code, a call to sleep coded as an instance
method stuck out like a sore thumb. Better that way than sloppy
thinking leading to a bug without the convention stepping in at all.

You didn't say how you coded your fix, but if you just used
a call like Thread.sleep, then you weren't following your
recommended coding convention either. To do so, you would
have to code something like
Thread thisThread = Thread.currentThread();
thisThread.sleep(...);

Well, no. Quite the opposite, actually. Since I've been saying for
some time that "thisThread.sleep(...)" is exactly what should not
happen... I'm just confused about where you're coming from.

But most wouldn't bother with that, they would just
call Thread.sleep(...);

Which is the right way to do it.

I just don't believe I should have to understand how a class
and its instances are implemented and what their inheritance
hierarchy is in order to follow this coding convention. I
don't know how fully you intend to go with it, but if
there's some class inheritance hierarchy like A.B.C.D
and I have an instance of D called d, and I want to invoke
some static method that happens to be defined up in B, are
you suggesting I code B.methodB(), and then for some method
in A, A.methodA(), and for C, C.methodC()?

I'm confused about why it matters that you've got an instance of D
called d. That instance has nothing to do with your desire to invoke
static methods. I'm still trying to figure out why hints of instance
method usage keep creeping into a discussion of static methods, as if
there is little difference between the two.

As for the question you asked here, anything that at least looks like a
static method is preferable to something that doesn't. So you'd write
"D.method()" or "B.method()" or whatever, as long as you don't write
"d.method()". In general, most static methods naturally belong in the
class they are declared in, so it would make sense to say, for example,
DateFormat.getDateInstance instead of SimpleDateFormat.getDateInstance.
But if a programmer working for me has trouble remembering where a
static method is declared, I'd much rather the programmer still stick
with static method syntax and just use the wrong class name.

So I should
encode the class hierarchy in all my calls to static methods
(after I first research it all to see what's static and what
isn't) ??

There again, an implication that you'd know what method you want to
call, what its name and arguments are, and how it behaves, but somehow
*not* even realize something as fundamental as that it's a static
method?!? I've asked before and gotten no answer: how could you
possibly be in that situation?

Another reason I might not follow the guideline is when the
class name happens to be 38 characters long, one of which I
saw yesterday.

I suppose I can imagine that being an annoyance. I just wouldn't choose
a medicine that's worse than the illness. Luckily, in Java 1.5 the new
static import facility will remove this problem far more elegantly.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation