File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JForum and the fly likes Stricter warnings? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JForum
Bookmark "Stricter warnings?" Watch "Stricter warnings?" New topic
Author

Stricter warnings?

Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
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

Joined: Apr 22, 2012
Posts: 17424
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

Joined: Apr 22, 2012
Posts: 17424
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

Joined: Apr 22, 2012
Posts: 17424
Eclipse warning-check is clearly brain-damaged
[originally posted on jforum.net by Daniil]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
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

Joined: Apr 22, 2012
Posts: 17424
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.
 
subject: Stricter warnings?