Syntax patterns: more statistics.

Ruslan Shevchenko Ruslan at Shevchenko.Kiev.UA
Tue Apr 21 00:15:09 PDT 2009


> It is indeed good work, but like all metrics, these measurements need
> to be treated as rough indicators rather than firm values.  The

 Yes.

> Jackpot project (an automated refactoring tool) had a rule to change
> if statements to conditional expressions -- it found a lot of
> candidates, but most were rejected by developers using the tool.  When
> asked, developers gave readability as the primary concern, stating
> that it was worth some verbiage to make the code easier to read.  My
> hunch is that a lot of potential elvis uses will be rejected for
> similar reasons.
>

Yes.
 How we can count this: look at languages where elvis implemented and
find percentage of applicability. What we need for this (?) - just parser.
So, in priniciple if exists publicy aviable groovy or C# parser (or
compiler/interpreter which provide access to AST), we can try hack one, to
count unused possibilities and expect that in java number would be near.


> Tom
>
> On Mon, Apr 20, 2009 at 3:24 PM, Stephen Colebourne
> <scolebourne at joda.org> wrote:
>> 2009/4/20 Ruslan Shevchenko <Ruslan at shevchenko.kiev.ua>:
>>> Main changes from previous post are:
>>> ═- added counts for 'if' syntax constructions, so we can say, hom many
>>> ═percents of if's can be eliminated by elvis operator ( [4-5]%)
>>> ═- added counts for 'catch' syntax constructions, so we can say that
>>> multicath eliminate 6-8% of all catch clauses.
>>> ═- added count for big integers integers (where undescore can be
>>> applicable, I guess this is x: x > 100000 || x < -10000) and for all
>>> integer literals.
>>> ═ (underscore can be applicable to near 1%)
>>> ═- added count for object-switch proposal by Ulf Zibis (refining, that
>>> Left/Right part of expressions are first operand in equalirty
>>> expression
>>> or object in method call)
>>> ═- added count for rethrow proposal by Mark Mahieu (near 50% of all
>>> catches in some packages (!) ).
>>> ═- added count for catches inside finally block. (Is this is a real
>>> problem [?]).
>>
>> Good work, and some interesting figures - multi-catch and elvis are
>> both higher than I would have guessed.
>>
>> Stephen
>>
>>
>
>





More information about the coin-dev mailing list