• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Stricter warnings?

 
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have relatively strict warning settings in eclipse, and I have caught quite a number of potential bugs that way (or at least was forced to cleanup my code).

As a consequence I get 52 warnings in the current jforum source (this might seem a lot but it is actually very low for a project of the size of jforum!)

Are you open to introduce some more striict warning settings? If so I will find out which settings produce the current warnings I get, and discuss them here individually to see if it is an option to introduce these settings in the jforum project.

[originally posted on jforum.net by Pieter]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, go ahead. I have some settings too, like "add 'this' to every class member" etc..

Please post your suggestions.

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suggest turning on the following:
- Unnecessary cast or instanceof operator: 3x
- Unused or unread private member 7x
- Local variable is never read 8x
- Empty statement 3x
- Local variable declaration hides another field or variable: 3x
(I usually uncheck "include constructor or setter method params", so I can use
this.field = field style assignment in those methods)
- field declaration hides another field or variable 0x

These are all trivial to fix and most of them make the code more readable (except maybe for the Empty statement which is more of a style issue than readability)

If we fix these, there is one killer left:
- access to non-accessible member of an enclosing type: 28x

This one is not trivial to fix, and maybe you don't want it fixed. This warning signals that in an inner class you use a method or field that is normally not accessible. To fix this, the compiler generates an artificial method with the right accessibility (default accessibility I would guess), and generates a method call instead of the direct access.

[originally posted on jforum.net by Pieter]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eclipse warning-check is clearly brain-damaged
[originally posted on jforum.net by Daniil]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pieter wrote:I suggest turning on the following:
- Unnecessary cast or instanceof operator: 3x
- Unused or unread private member 7x
- Local variable is never read 8x
- Empty statement 3x
- Local variable declaration hides another field or variable: 3x
(I usually uncheck "include constructor or setter method params", so I can use
this.field = field style assignment in those methods)
- field declaration hides another field or variable 0x



Ok for all. Also add

- Assignment has no effect
- Unqualified access to instance field

This last will result on almost 2.000 hits , but we should fix someday...

These are all trivial to fix and most of them make the code more readable (except maybe for the Empty statement which is more of a style issue than readability)

Pieter wrote:
If we fix these, there is one killer left:
- access to non-accessible member of an enclosing type: 28x

This one is not trivial to fix, and maybe you don't want it fixed. This warning signals that in an inner class you use a method or field that is normally not accessible. To fix this, the compiler generates an artificial method with the right accessibility (default accessibility I would guess), and generates a method call instead of the direct access.



The "... Increasing its visiblity will improve your performance.. " is really interesting

To me, we turn on all these suggestions, but I would like to do this after the release of RC 4, as making this little fixes will require changes on many files, and I want to prevent bugs of this kind ( *prevent* )

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree completely. I suspect that the "increase of performance" will not hold on JVM's with a decent JIT compiler because the extra method can be inlined with no problem, but that is just speculation.
[originally posted on jforum.net by Pieter]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic