Style of coding

[howachen]

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 ?

 

[Stefan Ram]

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; }}

 

[howachen]

Stefan Ram 寫é“：

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!

 

[IchBin]

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

 

[Oliver Wong]

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

 

[IchBin]

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

 

[Stefan Ram]

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.

 

[howachen]

Oliver Wong 寫é“：

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?

 

[Oliver Wong]

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

 

[Stefan Ram]

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

 

[Chris Uppal]

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]

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]

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

 

[Thomas Hawtin]

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

 

[Stefan Ram]

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.

 

[Mark Space]

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;
}
}


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.

 

[Stefan Ram]

Or even better:
public Person(String name) {

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

 

[Thomas Hawtin]

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

Tom Hawtin

 

[Thomas Hawtin]

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

 

[Mark Space]

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.