Java Code Convention Guidelines question...

Discussion in 'Java' started by New, Dec 31, 2003.

  1. New

    New Guest

    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
     
    New, Dec 31, 2003
    #1
    1. Advertising

  2. New

    Brian Palmer Guest

    (New) writes:

    > 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?

    --
    See comp.lang.java.announce for java-related announcements
     
    Brian Palmer, Dec 31, 2003
    #2
    1. Advertising

  3. New

    Roedy Green Guest

    On 31 Dec 2003 15:01:07 -0800, (New) wrote or
    quoted :

    > 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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Dec 31, 2003
    #3
  4. New

    Lee Weiner Guest

    In article <>, (New) wrote:
    >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
     
    Lee Weiner, Dec 31, 2003
    #4
  5. New

    Chris Smith Guest

    Lee Weiner wrote:
    > >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!

    >
    > 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
     
    Chris Smith, Jan 1, 2004
    #5
  6. New

    Jezuch Guest

    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
     
    Jezuch, Jan 1, 2004
    #6
  7. New

    rkm Guest

    Chris Smith wrote:
    > Lee Weiner wrote:
    >
    >>>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!

    >>
    >>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.
    >



    "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
     
    rkm, Jan 3, 2004
    #7
  8. New

    Chris Smith Guest

    rkm wrote:
    > "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
     
    Chris Smith, Jan 5, 2004
    #8
  9. New

    rkm Guest

    Chris Smith wrote:
    > rkm wrote:
    >
    >>"dangerously misleading"?
    >>

    > Yep.

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

    >>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.
    >

    Again, show an example.

    >
    >>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!
    >

    How is it a problem? An example please!

    >
    >>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.
    >

    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
     
    rkm, Jan 5, 2004
    #9
  10. New

    Chris Smith Guest

    rkm wrote:
    > > 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.


    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
     
    Chris Smith, Jan 6, 2004
    #10
  11. New

    rkm Guest

    Chris Smith wrote:
    > rkm wrote:
    >
    >>>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.

    >
    >
    > 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(...);

    >>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?
    >

    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
     
    rkm, Jan 9, 2004
    #11
  12. New

    Chris Smith Guest

    rkm wrote:
    > > 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.


    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
     
    Chris Smith, Jan 9, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JIT

    Code Guidelines

    JIT, Oct 4, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    526
    Rajesh Kumar
    Nov 2, 2004
  2. Sameer
    Replies:
    1
    Views:
    385
    Oscar kind
    Mar 7, 2005
  3. Marco
    Replies:
    19
    Views:
    839
    Dave Vandervies
    Apr 12, 2006
  4. Replies:
    5
    Views:
    323
    Roedy Green
    Jul 13, 2007
  5. Garrett Smith

    Code Guidelines

    Garrett Smith, Dec 21, 2009, in forum: Javascript
    Replies:
    111
    Views:
    865
    Garrett Smith
    Jan 9, 2010
Loading...

Share This Page