Loading...

gendarme@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [gendarme] Re: PMD like EmptyIf and EmptyFinally rules Sebastien Pouliot Wed Sep 01 19:00:22 2010

Hello Andres,

On Wed, 2010-09-01 at 14:05 +0200, "Andrés G. Aragoneses" wrote:
> El 31/08/10 23:45, Eric Zeitler escribió:
> >  On 8/31/2010 1:41 PM, Alexandre Victoor wrote:
> >> Hello,
> >> I have zipped the code, which is far from being perfect, of my two
> >> first gendarme rules. Let me know if there is a better way to share code. 
> >> Your feedback is welcomed.
> >> Regards
> >>
> >> Alex
> >> -- 
> >> You received this message because you are subscribed to the Google
> >> Groups "Gendarme" group.
> >> To post to this group, send email to [EMAIL PROTECTED]
> >> To unsubscribe from this group, send email to
> >> [EMAIL PROTECTED]
> >> For more options, visit this group at
> >> http://groups.google.com/group/gendarme?hl=en.
> > I tested these rules out on a bunch of assemblies compiled using 'mcs'
> > with optimizations on and the rules never triggered. I tried on the test
> > cases too just to make sure I didn't accidentally have perfect code :)
> > and no-go. I figured out turning optimization off lets them trigger like
> > intended.
> > 
> > In the gendarme solution the unit test projects have optimization on but
> > that didn't seem to break any other rules. With the optimized
> > assemblies, just the condition is emitted for the empty-if-tests.
> > 
> > As an enhancement to gendarme framework, each assembly could be checked
> > for compiler settings so rules that depend on optimization settings or
> > release/debug mode (or any other assembly processing, like
> > code-contracts or signing) can detect they won't work as intended and
> > emit a warning. Though this could just as easily be set in the comments
> > of the rules themselves.
> 
> My 2cents:
> I don't think in general that this kind of rules should belong to
> Gendarme 

I disagree :) The only cases where a rule does not belong in Gendarme
would be "duplication" (i.e. an existing rule covers this) or a rule
that report "too many" false positives to prove useful.

> (at least by default) 

As much as possible all rules are "on" by default and try (very hard) to
turn themselves off when non applicable (e.g. a 2.0 feature when
analyzing 1.x code).

Some cases for not being defaults are:

* huge performance or time/memory requirement (e.g. code duplication
smells)

* specialty rules (e.g. smells or, like mentioned in this thread, non-fx
tech-specific rules like log4net, nunit...)

> if they do not trigger anything when turning on optimizations. 

I wish it could be as easy but every compiler is different (and each
version also differs). Let's not assume CSC (or even MCS) as a basis for
rule usefulness decisions.

> That is, Gendarme is a tool for fixing code,
> not for fixing compilers.

While this statement is true I do not believe it to be applicable here.

Gendarme is used differently by several people, e.g. during development
(where debug symbols and lack of optimization are more likely), QA (with
or without symbols) or finding problems in existing software (like
quality evaluation before buying a software package).

Each case is different and some rules are "better fit" than others wrt
to your goal. I can see the value of this rule in early development
(well value would be there later if not optimized out ;-) since those
empty blocks are likely blocks that should NOT be empty (but that useful
information is sadly lost when optimizing).

Sebastien

-- 
You received this message because you are subscribed to the Google Groups 
"Gendarme" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/gendarme?hl=en.