I can live with that setting although the parameter never read is one
that I prefer to fix and in the medium term it would be good to add
the serializable field in our component template as it would save a
lot of grief to new users.
How do you want me to do this in practice? I don't have commit access
so I can send diff but it may be a bit tedious....
Pierre
On 17-Sep-06, at 11:59 AM, Mike Schrag wrote:
> I think Pierre and I must run with a lot more of the stock Eclipse
> warnings enabled since you only have 12 warnings visible. Here are
> some notable ones that I love and/or hate :)
>
> Warnings that Can Catch Bugs
> * Deprecation (not so much bugs, but just good to know)
> * Local variable is never read (might imply that you used the wrong
> variable somewhere)
> * Unused local or private member (same)
> * All the Name Shadowing warnings (this is just ASKING for bugs).
> The only one I am likely to turn off is "field hides another field"
> because it doesn't have an option to turn off checks for static
> fields (Project Wonder has _Entity.log and Entity.log that triggers
> this otherwise). Every other one of these is just a good idea
> * All the Potential Programming Problems warnings except Box/Unbox
> and Serializable
> * Parameter assignment
> * Undocumented empty block
>
> Warnings that Don't Catch Bugs, but I Like to Fix Them
> * Non-static access to static member
> * Unused import
> * Unnecessary else statement
> * Unnecessary cast or instanceof
> * Unnecessary declaration of thrown exception (this can give false
> positives because of subclasses, though)
>
> Warnings I Don't Like
> * Parameter is never read (this can give false positives because of
> subclasses)
> * Discouraged access rules (this was a really obnoxious addition to
> Eclipse plugins because they hide tons of API that we use)
> * Serializable (this catches a lot of stuff with WO)
> * Unqualified access to an instance field (I personally hate
> this.whatever)
>
> ms
>
> On Sep 17, 2006, at 2:04 PM, Ulrich Köster wrote:
>
>> First of all. The problems view includes a nice filter:
>>
>>
>> <Bild 5.png>
>>
>> <Bild 6.png>
>>
>>
>> A concerted effort would be something new for us. :-)
>>
>> I'm working on http://objectstyle.org/jira/browse/WOL-298 for quite a
>> while. Most of the warnings belong to this task. You're welcome to
>> reduce the numbers. (I'm doing that whenever I have the time for
>> that. The deprecation stuff raised the number again.)
>>
>> The settings are in the svn. Any comments?
>>
>> Uli
>>
>> Am 17.09.2006 um 18:39 schrieb Mike Schrag:
>>
>>> The first step is probably to agree on what warning sets we care
>>> about and commit those preferences into SVN. For instance, if you
>>> turn on all warnings in Eclipse, there are some that you can't
>>> actually fix without breaking things (unusued variables and
>>> exceptions that are actually used by subclasses, for instance).
>>> But I agree with you, I'd like to pick the warnings we
>>> collectively think are important and knock them out. I did a
>>> pass on Project Wonder just this past weekend and it's so nice to
>>> have an empty warnings list.
>>>
>>> ms
>>>
>>> On Sep 17, 2006, at 12:11 PM, Pierre Frisch wrote:
>>>
>>>> Could we make a concerted effort to remove warnings when
>>>> compiling wolips there are over 300 warnings when building
>>>> wolips and the number is growing not diminishing!!! I really
>>>> think we should try to reduce that number to 0. This is annoying
>>>> for me as I am trying to work on wolips while having other
>>>> projects open and I both sets of warning mix. I have always
>>>> believe that warning are important and I have found over the
>>>> year that fixing them pays big dividends when you look for that
>>>> hard to find bug.
>>>>
>>>> Yes I am ready to volunteer and do some of the work.
>>>>
>>>> Thank you for the good work
>>>>
>>>> Pierre
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Sun Sep 17 2006 - 17:04:37 EDT