Style of coding

Discussion in 'Java' started by howachen@gmail.com, Jul 4, 2006.

  1. Guest

    Consider the following styles, which one is preferred....

    1.
    public class Person {

    private String name;

    public void setName(String n) {
    this.name = n;
    }
    }

    2.
    public class Person {

    private String name;

    public void setName(String n) {
    name = n;
    }
    }


    and...if in case of static ....

    3.
    public class Person {

    private static String name;

    public static void setName(String n) {
    Person.name = n;
    }
    }

    4.
    public class Person {

    private static String name;

    public static void setName(String n) {
    name = n;
    }
    }


    1 or 2

    3 or 4 ?
     
    , Jul 4, 2006
    #1
    1. Advertising

  2. Stefan Ram Guest

    writes:
    >Consider the following styles, which one is preferred....
    >public class Person {
    > private String name;


    public class Person
    { private java.lang.String name;
    public void setName( final java.lang.String name )
    { this.name = name; }}
     
    Stefan Ram, Jul 4, 2006
    #2
    1. Advertising

  3. Guest

    Stefan Ram 寫é“:

    > writes:
    > >Consider the following styles, which one is preferred....
    > >public class Person {
    > > private String name;

    >
    > public class Person
    > { private java.lang.String name;
    > public void setName( final java.lang.String name )
    > { this.name = name; }}


    hi again :)

    it is quite rare to see people to use the "final" keyword, what is the
    exact advantage of doing so?

    thanks again!
     
    , Jul 4, 2006
    #3
  4. IchBin Guest

    wrote:
    > Consider the following styles, which one is preferred....
    >
    > 1.
    > public class Person {
    >
    > private String name;
    >
    > public void setName(String n) {
    > this.name = n;
    > }
    > }
    >
    > 2.
    > public class Person {
    >
    > private String name;
    >
    > public void setName(String n) {
    > name = n;
    > }
    > }
    >
    >
    > and...if in case of static ....
    >
    > 3.
    > public class Person {
    >
    > private static String name;
    >
    > public static void setName(String n) {
    > Person.name = n;
    > }
    > }
    >
    > 4.
    > public class Person {
    >
    > private static String name;
    >
    > public static void setName(String n) {
    > name = n;
    > }
    > }
    >
    >
    > 1 or 2
    >
    > 3 or 4 ?
    >

    Personally I prefer (opening Bracket on next line makes nested logic
    easy to read):

    public class Person
    {
    private String name;

    public void setName(String name)
    {
    this.name = name;
    }
    }

    Thanks in Advance...
    IchBin, Pocono Lake, Pa, USA http://weconsultants.phpnet.us
    __________________________________________________________________________

    'If there is one, Knowledge is the "Fountain of Youth"'
    -William E. Taylor, Regular Guy (1952-)
     
    IchBin, Jul 4, 2006
    #4
  5. Oliver Wong Guest

    <> wrote in message
    news:...
    >
    > it is quite rare to see people to use the "final" keyword, what is the
    > exact advantage of doing so?


    It indicates that you don't intend for the value to change. This can
    help you catch, at compile time, code which erroneously changes the value of
    those variables.

    Also, anonymous inner classes can only access surrounding local
    variables if they are final.

    - Oliver
     
    Oliver Wong, Jul 4, 2006
    #5
  6. IchBin Guest

    wrote:
    > Consider the following styles, which one is preferred....
    >
    > 1.
    > public class Person {
    >
    > private String name;
    >
    > public void setName(String n) {
    > this.name = n;
    > }
    > }
    >
    > 2.
    > public class Person {
    >
    > private String name;
    >
    > public void setName(String n) {
    > name = n;
    > }
    > }
    >
    >
    > and...if in case of static ....
    >
    > 3.
    > public class Person {
    >
    > private static String name;
    >
    > public static void setName(String n) {
    > Person.name = n;
    > }
    > }
    >
    > 4.
    > public class Person {
    >
    > private static String name;
    >
    > public static void setName(String n) {
    > name = n;
    > }
    > }
    >
    >
    > 1 or 2
    >
    > 3 or 4 ?
    >



    Personally I prefer (opening Bracket on next line makes nested logic
    easy to read):

    public class Person
    {
    private String name;

    public void setName(String name)
    {
    this.name = name;
    }
    }

    Thanks in Advance...
    IchBin, Pocono Lake, Pa, USA http://weconsultants.phpnet.us
    __________________________________________________________________________

    'If there is one, Knowledge is the "Fountain of Youth"'
    -William E. Taylor, Regular Guy (1952-)



    --

    Thanks in Advance...
    IchBin, Pocono Lake, Pa, USA http://weconsultants.phpnet.us
    __________________________________________________________________________

    'If there is one, Knowledge is the "Fountain of Youth"'
    -William E. Taylor, Regular Guy (1952-)
     
    IchBin, Jul 4, 2006
    #6
  7. Stefan Ram Guest

    writes:
    >>public void setName( final java.lang.String name )

    >it is quite rare to see people to use the "final" keyword, what is the
    >exact advantage of doing so?


    It is intended to be somewhat similar to the »in« in Ada:

    procedure Average(A, B : in Integer; Result : out Integer);

    (That was Ada, not Java.)

    It expresses my intention only to read from the parameter and
    not to change the binding of the name »name« - though, of
    course, the semantics of the »final« in Java are not the same
    as those of »in« in Ada or »const« in C.

    If I would inadvertently change the in-Parameter, the compiler
    could issue a warning. But it also helps human readers to
    grasp my intention never to change the binding of the
    name »name« within this method declaration.
     
    Stefan Ram, Jul 4, 2006
    #7
  8. Guest

    Oliver Wong 寫é“:

    > <> wrote in message
    > news:...
    > >
    > > it is quite rare to see people to use the "final" keyword, what is the
    > > exact advantage of doing so?

    >
    > It indicates that you don't intend for the value to change. This can
    > help you catch, at compile time, code which erroneously changes the valueof
    > those variables.
    >
    > Also, anonymous inner classes can only access surrounding local
    > variables if they are final.
    >
    > - Oliver


    thanks...then using "final" is really a good practice that every java
    programmer should know....

    btw, any comment on the style of static class as above?
     
    , Jul 4, 2006
    #8
  9. Oliver Wong Guest

    <> wrote in message
    news:...
    >
    > btw, any comment on the style of static class as above?


    Not really. I usually prefer to fully qualify names (which means using
    "this." or the classname when appropriate), but some of my coworkers prefer
    not to. It looks like I'm not bothered by really long identifier names at
    all, while they are.

    - Oliver
     
    Oliver Wong, Jul 4, 2006
    #9
  10. Stefan Ram Guest

    "Oliver Wong" <> writes:
    > Not really. I usually prefer to fully qualify names (which means using
    >"this." or the classname when appropriate), but some of my coworkers prefer


    I am extreme in this regard. I always prefer the full path and
    never use »import«. So I write »java.lang.System.out.println«.

    I also like descriptive names.
    Recently I modified my Java-preprocessor: Now, I can write:

    boolean 'can be extended by'( final int cp );

    My preprocessor will convert this to

    boolean canBeExtendedBy( final int cp );

    (It usually will leave character literals untouched.)
     
    Stefan Ram, Jul 4, 2006
    #10
  11. Chris Uppal Guest

    wrote:

    > this.name = n;

    vs.
    > name = n;


    I, personally, would prefer to be forced by the compiler to use the first form.
    However that isn't how Java works, and there's nothing to be gained by
    insisting on that form. It's probably better /not/ to use it, so that you
    don't become dependent on it, and thus have unecessary difficulty reading other
    people's code.

    The same goes for the static case.

    BTW, I agree with IchBin's layout of brackets.

    -- chris
     
    Chris Uppal, Jul 4, 2006
    #11
  12. Chris Uppal Guest

    Stefan Ram wrote:

    > I am extreme in this regard. I always prefer the full path and
    > never use »import«. So I write »java.lang.System.out.println«.


    Now that /is/ extreme. I'm on record as opining that import can be over-used
    (and hence that wildcard imports are a Good Thing), but even in my most
    pedantic moments, I would not dream of going quite that far ;-)


    > I also like descriptive names.
    > Recently I modified my Java-preprocessor: Now, I can write:
    >
    > boolean 'can be extended by'( final int cp );
    >
    > My preprocessor will convert this to
    >
    > boolean canBeExtendedBy( final int cp );


    A perfectly reasonable name in itself, so I'm a bit puzzled by the need for a
    preprocessor for it -- presumably converting 'can be extended by'() into
    canBeExtendedBy() is only a small part of what it does ?

    -- chris
     
    Chris Uppal, Jul 4, 2006
    #12
  13. Chris Uppal Guest

    Oliver Wong wrote:

    > > it is quite rare to see people to use the "final" keyword, what is the
    > > exact advantage of doing so?

    >
    > It indicates that you don't intend for the value to change. This can
    > help you catch, at compile time, code which erroneously changes the value
    > of those variables.


    Or, to put that another way, it's a waste of time when used for a parameter or
    local variable.

    If you don't want to change the value of a local variable, then don't change
    it...


    > Also, anonymous inner classes can only access surrounding local
    > variables if they are final.


    True, and that /is/ a valid and important use.

    -- chris
     
    Chris Uppal, Jul 4, 2006
    #13
  14. wrote:
    > Consider the following styles, which one is preferred....


    The convention is:

    public class Person {

    private String name;

    public void setName(String name) {
    this.name = name;
    }
    }

    No point making up new names to represent the same concept.

    Or even better:

    public final class Person {

    private final String name;

    public Person(String name) {
    this.name = name;
    }
    }

    > and...if in case of static ....
    >
    > 3.
    > public class Person {
    >
    > private static String name;
    >
    > public static void setName(String n) {
    > Person.name = n;
    > }
    > }


    The problem here is that you have a non-final static, which is almost
    certainly a mistake.

    In the case of static finals, you cannot qualify with the class name
    (which can be a bit of a pain in static initialisers).

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Jul 4, 2006
    #14
  15. Stefan Ram Guest

    "Chris Uppal" <-THIS.org> writes:
    >> boolean 'can be extended by'( final int cp );
    >> My preprocessor will convert this to
    >> boolean canBeExtendedBy( final int cp );

    >A perfectly reasonable name in itself, so I'm a bit puzzled by
    >the need for a preprocessor for it -- presumably converting
    >'can be extended by'() into canBeExtendedBy() is only a small
    >part of what it does ?


    The notation with spaces looks more readable to me.

    Maybe examples with even longer names can show this:

    void 'set start state to false'(){ this.start = false; }

    public void advance( final java.lang.String text )
    { this.'set start state to false'();
    this.offset += text.length() - 1; this.justify(); }

    /* ... */

    if( token.'can be extended by'( cursor1.'code point' ))
    { cursor1.advance(); looping = cursor1.'is within source text'(); }

    /* ... */

    I am using the general preprocessor gpp for most purposes

    http://www.nothingisreal.com/gpp/

    while the feature mentioned to convert 'can be extended by'
    to 'canBeExtendedBy' is added via a Perl script.
     
    Stefan Ram, Jul 4, 2006
    #15
  16. Mark Space Guest

    Thomas Hawtin wrote:
    > wrote:
    >> Consider the following styles, which one is preferred....

    >
    > The convention is:
    >
    > public class Person {
    >
    > private String name;
    >
    > public void setName(String name) {
    > this.name = name;
    > }
    > }
    >
    > No point making up new names to represent the same concept.
    >
    > Or even better:
    >
    > public final class Person {
    >
    > private final String name;
    >
    > public Person(String name) {
    > this.name = name;
    > }
    > }
    >
    >> and...if in case of static ....
    >>
    >> 3.
    >> public class Person {
    >>
    >> private static String name;
    >>
    >> public static void setName(String n) {
    >> Person.name = n;
    >> }
    >> }

    >
    > The problem here is that you have a non-final static, which is almost
    > certainly a mistake.
    >
    > In the case of static finals, you cannot qualify with the class name
    > (which can be a bit of a pain in static initialisers).
    >
    > Tom Hawtin


    Huh, why do you say that? Do you mean in this specific example (which I
    might be inclined to agree)? Or do you mean in general (which I might
    be inclined to disagree)?

    I don't see anything in class variables in general that makes them
    "almost certainly a mistake," but maybe there is something I'm missing.
    Class variables are a good and useful concept, and I don't see anything
    wrong with using them.
     
    Mark Space, Jul 4, 2006
    #16
  17. Stefan Ram Guest

    Thomas Hawtin <> writes:
    >Or even better:
    > public Person(String name) {


    Does a person become a new person, when it changes its name?
     
    Stefan Ram, Jul 4, 2006
    #17
  18. Mark Space wrote:
    > Thomas Hawtin wrote:


    >> The problem here is that you have a non-final static, which is almost
    >> certainly a mistake.
    >>
    >> In the case of static finals, you cannot qualify with the class name
    >> (which can be a bit of a pain in static initialisers).


    > Huh, why do you say that? Do you mean in this specific example (which I
    > might be inclined to agree)? Or do you mean in general (which I might
    > be inclined to disagree)?


    I mean mutable statics in general are bad.

    You are making an assumption about the system in a single class. Ever
    tried handling an applet (or servlet) with static variables? Nightmare.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Jul 4, 2006
    #18
  19. Stefan Ram wrote:
    > Thomas Hawtin <> writes:
    >> Or even better:
    >> public Person(String name) {

    >
    > Does a person become a new person, when it changes its name?


    It's better that than changing his or her name without telling anyone...

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Jul 4, 2006
    #19
  20. Mark Space Guest

    Thomas Hawtin wrote:
    > Mark Space wrote:
    >> Huh, why do you say that? Do you mean in this specific example (which I
    >> might be inclined to agree)? Or do you mean in general (which I might
    >> be inclined to disagree)?

    >
    > I mean mutable statics in general are bad.
    >
    > You are making an assumption about the system in a single class. Ever
    > tried handling an applet (or servlet) with static variables? Nightmare.



    Hmm, well, I've never done any work with applets, so I'll reserve
    judgment. It sounds to me like maybe class variables were used where
    the should not have been, but I don't know the full story.
     
    Mark Space, Jul 4, 2006
    #20
    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. Paul Baxter

    style for coding latches

    Paul Baxter, Aug 10, 2003, in forum: VHDL
    Replies:
    7
    Views:
    1,155
    Mike Treseler
    Aug 15, 2003
  2. Willem Oosthuizen

    Coding style to prioritize certain inputs

    Willem Oosthuizen, Sep 2, 2003, in forum: VHDL
    Replies:
    5
    Views:
    503
    Mike Treseler
    Sep 4, 2003
  3. Analog Guy

    Coding style for CPLD vs FPGA

    Analog Guy, Mar 11, 2005, in forum: VHDL
    Replies:
    3
    Views:
    5,471
    Klaus Falser
    Mar 14, 2005
  4. calmar
    Replies:
    11
    Views:
    918
    calmar
    Feb 21, 2006
  5. Ken Varn
    Replies:
    0
    Views:
    493
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page