Eclipse Community Forums: Eclipse Platform » Checkstyle "hides a field" strategy.

Help

Home

Home » Eclipse Projects » Eclipse Platform » Checkstyle "hides a field" strategy.

Show: Today's Messages :: Show Polls :: Message Navigator

Checkstyle "hides a field" strategy. [message #468321]

Wed, 05 August 2009 02:51

ali Mising name

Messages: 38
Registered: July 2009

Member

Hello all,

'Just wondering if anyone knows of any standard or common practices to
resolve this code style issue of "hides a field". I want to use meaningful
variable names for both of my local and class variables, but Im not sure
which one to modify of what to modify it too...

Does anyone insert trailing or leading characters to denote class
variables, or perhaps append the word "param" to the end of the parameter
names? I appreciate why and how this issue occurs I am seeking advice
about a standard naming approach to solving it (best practice).

Here's an example - checkstyle may complain that the "value" parameter
"hides a field":

public class MyClass {
private int value;
public void setValue(int value) {
this.value = value;
}
}

Report message to a moderator

Re: Checkstyle "hides a field" strategy. [message #468326 is a reply to message #468321]

Wed, 05 August 2009 05:33

Lars Vogel

Messages: 1098
Registered: July 2009

Senior Member

Hi,

If I remember correctly I have turned this check of. Best regards, Lars

ali wrote:
> Hello all,
>
> 'Just wondering if anyone knows of any standard or common practices to
> resolve this code style issue of "hides a field". I want to use
> meaningful variable names for both of my local and class variables, but
> I�m not sure which one to modify of what to modify it too...
>
> Does anyone insert trailing or leading characters to denote class
> variables, or perhaps append the word "param" to the end of the
> parameter names? I appreciate why and how this issue occurs � I am
> seeking advice about a standard naming approach to solving it (best
> practice).
>
> Here's an example - checkstyle may complain that the "value" parameter
> "hides a field":
>
> public class MyClass {
> private int value;
> public void setValue(int value) {
> this.value = value;
> }
> }
>

--
http://www.vogella.de/ - Eclipse plugin and Eclipse RCP Tutorials

Report message to a moderator

Re: Checkstyle "hides a field" strategy. [message #468329 is a reply to message #468326]

Wed, 05 August 2009 05:59

ali Mising name

Messages: 38
Registered: July 2009

Member

Yeah, that would be a bit easier, but I do like the "tough-love" of
abiding by this rule... I think in the long-run it will make code easier
to read (if I can settle on a good, standard way of implementing it). Any
advice from anyone else would be very welcome.

Report message to a moderator

Re: Checkstyle "hides a field" strategy. [message #468336 is a reply to message #468321]

Wed, 05 August 2009 07:24

Dani Megert

Messages: 3802
Registered: July 2009

Senior Member

ali wrote:
> Hello all,
>
> 'Just wondering if anyone knows of any standard or common practices to
> resolve this code style issue of "hides a field". I want to use
> meaningful variable names for both of my local and class variables,
> but I�m not sure which one to modify of what to modify it too...
>
> Does anyone insert trailing or leading characters to denote class
> variables, or perhaps append the word "param" to the end of the
> parameter names? I appreciate why and how this issue occurs � I am
> seeking advice about a standard naming approach to solving it (best
> practice).
Some Eclipse SDK components (e.g. JDT) use 'f' as prefix for instance
fields and 'fg' for static fields. Prefixes and suffixes are supported
by JDT (take a look at Java > Code Style preference page).

Dani
>
> Here's an example - checkstyle may complain that the "value" parameter
> "hides a field":
>
> public class MyClass {
> private int value;
> public void setValue(int value) {
> this.value = value;
> }
> }
>

Report message to a moderator

Re: Checkstyle "hides a field" strategy. [message #468437 is a reply to message #468321]

Wed, 05 August 2009 14:27

Eric Rizzo

Messages: 3070
Registered: July 2009

Senior Member

ali wrote:
> Hello all,
>
> 'Just wondering if anyone knows of any standard or common practices to
> resolve this code style issue of "hides a field". I want to use
> meaningful variable names for both of my local and class variables, but
> I�m not sure which one to modify of what to modify it too...
>
> Does anyone insert trailing or leading characters to denote class
> variables, or perhaps append the word "param" to the end of the
> parameter names? I appreciate why and how this issue occurs � I am
> seeking advice about a standard naming approach to solving it (best
> practice).
>
> Here's an example - checkstyle may complain that the "value" parameter
> "hides a field":
>
> public class MyClass {
> private int value;
> public void setValue(int value) {
> this.value = value;
> }
> }
>

In this particular case, I'd use a name for the method parameter like
newValue. In other situations, I often use names like aValue or aString
(comes from my Smalltalk background, where that is a "standard" naming
convention).

By the way, Eclipse does not use Chekstyle (the SourceForge project);
these things are called "compiler warnings" in Eclipse lingo.

Hope this helps,
Eric

Report message to a moderator

Re: Checkstyle "hides a field" strategy. [message #474801 is a reply to message #468437]

Wed, 05 August 2009 21:52

ali Mising name

Messages: 38
Registered: July 2009

Member

Hi Eric,

Thanks for the suggestions - I'm leaning heavily towards adding the word
"new" to my method parameters. I've seen that used before too - so it
"feels" like some sort of common approach. BTW, I am using a Checkstyle
plug-in for Eclipse and I am attempting to fully-accommodate the Sun
checkstyle rules.

Report message to a moderator

Previous Topic:	Icons from other projects
Next Topic:	Is it possible to replace the "Default Text Editor"

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 08:44:52 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter