unused statics?

Discussion in 'Java' started by bob smith, Jan 24, 2013.

  1. bob smith

    bob smith Guest

    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.
     
    bob smith, Jan 24, 2013
    #1
    1. Advertising

  2. bob smith

    Lew Guest

    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
     
    Lew, Jan 24, 2013
    #2
    1. Advertising

  3. bob smith

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jan 24, 2013
    #3
  4. bob smith

    Arne Vajhøj Guest

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


    Sometimes it improves readability.

    Arne
     
    Arne Vajhøj, Jan 24, 2013
    #4
  5. bob smith

    markspace Guest

    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.
     
    markspace, Jan 24, 2013
    #5
  6. bob smith

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jan 24, 2013
    #6
  7. bob smith

    Lew Guest

    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
     
    Lew, Jan 25, 2013
    #7
  8. bob smith

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jan 25, 2013
    #8
  9. bob smith

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jan 25, 2013
    #9
  10. 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
     
    Magnus Warker, Jan 25, 2013
    #10
  11. On Thu, 24 Jan 2013 18:07:39 -0500, Arne Vajhøj <>
    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
     
    Gene Wirchenko, Jan 25, 2013
    #11
  12. bob smith

    Roedy Green Guest

    On Thu, 24 Jan 2013 12:23:54 -0800 (PST), bob smith
    <> 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
     
    Roedy Green, Jan 26, 2013
    #12
  13. bob smith

    Arne Vajhøj Guest

    On 1/26/2013 5:53 AM, Roedy Green wrote:
    > On Thu, 24 Jan 2013 12:23:54 -0800 (PST), bob smith
    > <> 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
     
    Arne Vajhøj, Jan 26, 2013
    #13
  14. bob smith

    Arne Vajhøj Guest

    On 1/25/2013 12:36 PM, Gene Wirchenko wrote:
    > On Thu, 24 Jan 2013 18:07:39 -0500, Arne Vajhøj <>
    > 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
     
    Arne Vajhøj, Feb 24, 2013
    #14
    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. Jason

    Statics and connections

    Jason, Dec 6, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,765
    Jason
    Dec 6, 2004
  2. Roedy Green

    statics in inner classes

    Roedy Green, Jul 1, 2005, in forum: Java
    Replies:
    14
    Views:
    748
    Thomas G. Marshall
    Jul 12, 2005
  3. Roedy Green

    initialising statics

    Roedy Green, Jan 22, 2006, in forum: Java
    Replies:
    8
    Views:
    615
    John C. Bollinger
    Jan 27, 2006
  4. tom_usenet

    Re: statics/globals

    tom_usenet, Jun 15, 2004, in forum: C++
    Replies:
    0
    Views:
    431
    tom_usenet
    Jun 15, 2004
  5. Stuart MacMartin
    Replies:
    5
    Views:
    569
    Victor Bazarov
    Jul 27, 2005
Loading...

Share This Page