Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21664 > unrolled thread

unused statics?

Back to article view | Back to comp.lang.java.programmer

Contents

  unused statics? bob smith <bob@coolfone.comze.com> - 2013-01-24 12:23 -0800
    Re: unused statics? Lew <lewbloch@gmail.com> - 2013-01-24 12:31 -0800
      Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 15:45 -0500
        Re: unused statics? Patricia Shanahan <pats@acm.org> - 2013-01-24 13:15 -0800
          Re: unused statics? markspace <markspace@nospam.nospam> - 2013-01-24 13:54 -0800
          Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 18:07 -0500
            Re: unused statics? Lew <lewbloch@gmail.com> - 2013-01-24 17:16 -0800
              Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 20:31 -0500
                Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 20:35 -0500
              Re: unused statics? Patricia Shanahan <pats@acm.org> - 2013-01-24 17:38 -0800
              Re: unused statics? Magnus Warker <magnus@mailinator.com> - 2013-01-25 05:29 +0100
              Re: unused statics? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-25 08:42 +0000
            Re: unused statics? Gene Wirchenko <genew@telus.net> - 2013-01-25 09:36 -0800
              Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-02-24 17:55 -0500
    Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 15:43 -0500
    Re: unused statics? Roedy Green <see_website@mindprod.com.invalid> - 2013-01-26 02:53 -0800
      Re: unused statics? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:37 -0500

#21664 — unused statics?

So, I found this in one of my classes:

static int ctr = 0;

It turns out it wasn't being used anywhere.  I thought Eclipse would warn
me about this, but it didn't.  I looked thru the options, and I couldn't find anything to change.

Is there any way to get warned about those unused statics?

Thanks.

[toc] | [next] | [standalone]

#21665

bob smith wrote:
> So, I found this in one of my classes:
> 
> static int ctr = 0;
> 
> It turns out it wasn't being used anywhere.  I thought Eclipse would warn
> me about this, but it didn't.  I looked thru the options, and I couldn't find anything to change.
> 
> Is there any way to get warned about those unused statics?

Declare it private.

There's no way for a system to know if an accessible element is being accessed outside the project.

Why was it assigned its default value redundantly?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21667

On 1/24/2013 3:31 PM, Lew wrote:
> Why was it assigned its default value redundantly?

Sometimes it improves readability.

Arne

[toc] | [prev] | [next] | [standalone]

#21668

On 1/24/2013 12:45 PM, Arne Vajhøj wrote:
> On 1/24/2013 3:31 PM, Lew wrote:
>> Why was it assigned its default value redundantly?
>
> Sometimes it improves readability.

I often do that as a note to myself. It means I do expect to use the
initial value, have considered what the initial value should be, and
have chosen 0.

Patricia

[toc] | [prev] | [next] | [standalone]

#21669

On 1/24/2013 1:15 PM, Patricia Shanahan wrote:
> On 1/24/2013 12:45 PM, Arne Vajhøj wrote:
>> On 1/24/2013 3:31 PM, Lew wrote:
>>> Why was it assigned its default value redundantly?
>>
>> Sometimes it improves readability.
>
> I often do that as a note to myself. It means I do expect to use the
> initial value, have considered what the initial value should be, and
> have chosen 0.


Assignment is also required if the field is final, even if you intend to 
use the default value.

[toc] | [prev] | [next] | [standalone]

#21675

On 1/24/2013 4:15 PM, Patricia Shanahan wrote:
> On 1/24/2013 12:45 PM, Arne Vajhøj wrote:
>> On 1/24/2013 3:31 PM, Lew wrote:
>>> Why was it assigned its default value redundantly?
>>
>> Sometimes it improves readability.
>
> I often do that as a note to myself. It means I do expect to use the
> initial value, have considered what the initial value should be, and
> have chosen 0.

I think that it is easier to read code that are consistent
in initialization.

A class where all fields are initialized in declaration,
a class where all fields are initialized in constructor or a
class where all fields get default value is easy to understand
in my opinion.

If 1/3 of fields are are initialized in declaration, 1/3 in
constructor and 1/3 get get default value then the reader will
spend the first 10 minutes trying to guess what the developers
reason for doing so is.

Arne

[toc] | [prev] | [next] | [standalone]

#21679

Arne Vajhøj wrote:
> Patricia Shanahan wrote:
>> Arne Vajh�j wrote:
>>> Lew wrote:
>>>> Why was it assigned its default value redundantly?
>>> Sometimes it improves readability.

Not this time. Was it the OP's intention? Why not let the OP answer?

>> I often do that as a note to myself. It means I do expect to use the

Was that the OP's intention? Why not let the OP answer?

>> initial value, have considered what the initial value should be, and
>> have chosen 0.

In general, I agree. That didn't seem to apply here, so I asked the OP specifically 
why in this case they did that.
 
> I think that it is easier to read code that are consistent
> in initialization.
> 
> A class where all fields are initialized in declaration,
> a class where all fields are initialized in constructor or a
> class where all fields get default value is easy to understand
> in my opinion.
> 
> If 1/3 of fields are are initialized in declaration, 1/3 in
> constructor and 1/3 get get default value then the reader will
> spend the first 10 minutes trying to guess what the developers
> reason for doing so is.

There are engineering reasons for each of the three choices. Sometimes 
those reasons vary within the same class. So then you use comments to 
explain the divergence. Whenever I deem it worthwhile to take the tiny 
performance hit of redundantly assigning the same value to a member twice, 
I comment why it's done.

So I think you'd find that readable, too.

Here's why you need more than one way to do things:

public class Foo<T>
{
  private final Class<T> rttt;
  private boolean initialized = false; // explicitly initialized to emphasize the logic
  private Bar bar;

  public Foo(Class<T> rttt)
  {
    if (rttt == null) {throw new IllegalArgumentException("null rttt"); }
    this.rttt = rttt;
  }

  public void setBar(Bar bar)
  {
    this.bar = bar;
  }

  public Bar getBar() 
  {
    return bar;
  }
}

I see no readability problems with this.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21681

On 1/24/2013 8:16 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Patricia Shanahan wrote:
>>> Arne Vajh�j wrote:
>>>> Lew wrote:
>>>>> Why was it assigned its default value redundantly?
>>>> Sometimes it improves readability.
>
> Not this time.

I am not able to say whether a certain construct improve
readability or not based on a single line.

And as I explained later then my main criteria is
what the other lines do.

Do you use mind reading to see what the other lines are
or?

>             Was it the OP's intention?


To write readable code? I assume so!

>                                        Why not let the OP answer?

It is rather common to comment on comments here.

>> I think that it is easier to read code that are consistent
>> in initialization.
>>
>> A class where all fields are initialized in declaration,
>> a class where all fields are initialized in constructor or a
>> class where all fields get default value is easy to understand
>> in my opinion.
>>
>> If 1/3 of fields are are initialized in declaration, 1/3 in
>> constructor and 1/3 get get default value then the reader will
>> spend the first 10 minutes trying to guess what the developers
>> reason for doing so is.
>
> There are engineering reasons for each of the three choices. Sometimes
> those reasons vary within the same class. So then you use comments to
> explain the divergence. Whenever I deem it worthwhile to take the tiny
> performance hit of redundantly assigning the same value to a member twice,
> I comment why it's done.
>
> So I think you'd find that readable, too.

But having to comment on something that can be written so no
comments are necessary does not seem optimal. And one could still
wonder why.

> Here's why you need more than one way to do things:
>
> public class Foo<T>
> {
>    private final Class<T> rttt;
>    private boolean initialized = false; // explicitly initialized to emphasize the logic
>    private Bar bar;
>
>    public Foo(Class<T> rttt)
>    {
>      if (rttt == null) {throw new IllegalArgumentException("null rttt"); }
>      this.rttt = rttt;
>    }
>
>    public void setBar(Bar bar)
>    {
>      this.bar = bar;
>    }
>
>    public Bar getBar()
>    {
>      return bar;
>    }
> }
>
> I see no readability problems with this.

I do.

Not a big problem - far from.

But the asymmetry still gives a desire to spend more time to
read the code to try and understand why it was done this way.

Arne

[toc] | [prev] | [next] | [standalone]

#21682

On 1/24/2013 8:31 PM, Arne Vajhøj wrote:
> On 1/24/2013 8:16 PM, Lew wrote:
>> Arne Vajhøj wrote:
>>> Patricia Shanahan wrote:
>>>> Arne Vajh�j wrote:
>>>>> Lew wrote:
>>>>>> Why was it assigned its default value redundantly?
>>>>> Sometimes it improves readability.
>>
>> Not this time.
>
> I am not able to say whether a certain construct improve
> readability or not based on a single line.
>
> And as I explained later then my main criteria is
> what the other lines do.
>
> Do you use mind reading to see what the other lines are
> or?
>
>>             Was it the OP's intention?
>
>
> To write readable code? I assume so!
>
>>                                        Why not let the OP answer?
>
> It is rather common to comment on comments here.
>
>>> I think that it is easier to read code that are consistent
>>> in initialization.
>>>
>>> A class where all fields are initialized in declaration,
>>> a class where all fields are initialized in constructor or a
>>> class where all fields get default value is easy to understand
>>> in my opinion.
>>>
>>> If 1/3 of fields are are initialized in declaration, 1/3 in
>>> constructor and 1/3 get get default value then the reader will
>>> spend the first 10 minutes trying to guess what the developers
>>> reason for doing so is.
>>
>> There are engineering reasons for each of the three choices. Sometimes
>> those reasons vary within the same class. So then you use comments to
>> explain the divergence. Whenever I deem it worthwhile to take the tiny
>> performance hit of redundantly assigning the same value to a member
>> twice,
>> I comment why it's done.
>>
>> So I think you'd find that readable, too.
>
> But having to comment on something that can be written so no
> comments are necessary does not seem optimal. And one could still
> wonder why.
>
>> Here's why you need more than one way to do things:
>>
>> public class Foo<T>
>> {
>>    private final Class<T> rttt;
>>    private boolean initialized = false; // explicitly initialized to
>> emphasize the logic
>>    private Bar bar;
>>
>>    public Foo(Class<T> rttt)
>>    {
>>      if (rttt == null) {throw new IllegalArgumentException("null
>> rttt"); }
>>      this.rttt = rttt;
>>    }
>>
>>    public void setBar(Bar bar)
>>    {
>>      this.bar = bar;
>>    }
>>
>>    public Bar getBar()
>>    {
>>      return bar;
>>    }
>> }
>>
>> I see no readability problems with this.
>
> I do.
>
> Not a big problem - far from.
>
> But the asymmetry still gives a desire to spend more time to
> read the code to try and understand why it was done this way.

I would have done it as:

public class Foo<T> {
     private final Class<T> rttt;
     private boolean initialized;
     private Bar bar;
     public Foo(Class<T> rttt) {
       if (rttt == null) {throw new IllegalArgumentException("null rttt"); }
       this.rttt = rttt;
       this.initialized = false;
       this.bar = null;
     }
...

A quick glance on the constructor will tell what everything is
and because it seems consistent, then one would not worry and
check if there is something funky going on.

Arne

[toc] | [prev] | [next] | [standalone]

#21683

On 1/24/2013 5:16 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Patricia Shanahan wrote:
>>> Arne Vajh�j wrote:
>>>> Lew wrote:
>>>>> Why was it assigned its default value redundantly?
>>>> Sometimes it improves readability.
>
> Not this time. Was it the OP's intention? Why not let the OP answer?
>
>>> I often do that as a note to myself. It means I do expect to use the
>
> Was that the OP's intention? Why not let the OP answer?
...

Huh? You seem to have forgotten some basics of how newsgroups work. I
don't have to "let" the OP answer. I could not prevent the OP from
answering even if I wanted to do so. On the other hand, I am equally
free to express my opinions on the subject.

Patricia

[toc] | [prev] | [next] | [standalone]

#21691

On 01/25/2013 02:16 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Patricia Shanahan wrote:
>>> Arne Vajh�j wrote:
>>>> Lew wrote:
>>>>> Why was it assigned its default value redundantly?
>>>> Sometimes it improves readability.

> There are engineering reasons for each of the three choices.

This has absolutely nothing to do with "engineering reasons" or large 
software projects. It's just the bullshit of your personal microcosm.

Magnus

[toc] | [prev] | [next] | [standalone]

#21699

On 25/01/13 01:16, Lew wrote:
> Arne Vajhøj wrote:
>> Patricia Shanahan wrote:
>>> Arne Vajh�j wrote:
>>>> Lew wrote:
>>>>> Why was it assigned its default value redundantly?
>>>> Sometimes it improves readability.
>
> Not this time. Was it the OP's intention? Why not let the OP answer?

Speechless ...

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#21707

On Thu, 24 Jan 2013 18:07:39 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>I think that it is easier to read code that are consistent
>in initialization.

     Sure, but you are using a different sort of consistency.

     My consistency is to initialise as close to where the variable is
used.  If I need to change the initialisation for a section of code,
it is right there.

     That said, I prefer to have my declarations near the related
code.  I dislike languages that require all declarations before all
code in a block.

>A class where all fields are initialized in declaration,
>a class where all fields are initialized in constructor or a
>class where all fields get default value is easy to understand
>in my opinion.
>
>If 1/3 of fields are are initialized in declaration, 1/3 in
>constructor and 1/3 get get default value then the reader will
>spend the first 10 minutes trying to guess what the developers
>reason for doing so is.

     If they are all initialised in declarations, then the reader will
have to determine if that initialisation is really it.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#22490

On 1/25/2013 12:36 PM, Gene Wirchenko wrote:
> On Thu, 24 Jan 2013 18:07:39 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>
> [snip]
>
>> I think that it is easier to read code that are consistent
>> in initialization.
>
>       Sure, but you are using a different sort of consistency.
>
>       My consistency is to initialise as close to where the variable is
> used.  If I need to change the initialisation for a section of code,
> it is right there.
>
>       That said, I prefer to have my declarations near the related
> code.  I dislike languages that require all declarations before all
> code in a block.

????

I am talking about fields not local variables.

>> A class where all fields are initialized in declaration,
>> a class where all fields are initialized in constructor or a
>> class where all fields get default value is easy to understand
>> in my opinion.
>>
>> If 1/3 of fields are are initialized in declaration, 1/3 in
>> constructor and 1/3 get get default value then the reader will
>> spend the first 10 minutes trying to guess what the developers
>> reason for doing so is.

Arne

[toc] | [prev] | [next] | [standalone]

#21666

On 1/24/2013 3:23 PM, bob smith wrote:
> So, I found this in one of my classes:
>
> static int ctr = 0;
>
> It turns out it wasn't being used anywhere.  I thought Eclipse would warn
> me about this, but it didn't.  I looked thru the options, and I couldn't find anything to change.
>
> Is there any way to get warned about those unused statics?

I think you can only do that for private.

Eclipse have no way of knowing if are going to email
me the class file and I will write a program that use it.

A non final field should be private anyway according to
good OO practice.

Arne

[toc] | [prev] | [next] | [standalone]

#21731

On Thu, 24 Jan 2013 12:23:54 -0800 (PST), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>
>It turns out it wasn't being used anywhere.  I thought Eclipse would warn
>me about this, but it didn't.  I looked thru the options, and I couldn't find anything to change.

It has been a long time since I used Eclipse, but in IntelliJ you must
run the Inspector/lint.  you static is legal Java, just nugatory. 

googling "Eclipse Lint" gave me several packages, but did not clarify
if there is one built-in.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [next] | [standalone]

#21755

On 1/26/2013 5:53 AM, Roedy Green wrote:
> On Thu, 24 Jan 2013 12:23:54 -0800 (PST), bob smith
> <bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
> who said :
>> It turns out it wasn't being used anywhere.  I thought Eclipse would warn
>> me about this, but it didn't.  I looked thru the options, and I couldn't find anything to change.
>
> It has been a long time since I used Eclipse, but in IntelliJ you must
> run the Inspector/lint.

No tool should warn against this construct.

>                         you static is legal Java, just nugatory.

No. There can be lots of code using that static.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web