One more question how does everyone feel about moving to Java5 source
code compliance level? 5.0 source level compliance allows us to use
annotations and reduce the amount of type cast.
By the way I have 553 warnings with the settings that Mike proposed.
Pierre
On 17-Sep-06, at 2:04 PM, Pierre Frisch wrote:
> 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 : Wed Sep 20 2006 - 06:27:19 EDT