Re: Rails 1.2.0 RC2 has 4125 duplicate lines

Rob Biedenharn
Mon, 15 Jan 2007 20:18:03 -0000

On Jan 14, 2007, at 4:06 PM, Justin Forder wrote:
> Rob Sanheim wrote:
>> On 1/10/07, Jean-Michel G
<address4spams-60m4EJPkapScg7rPLOrFbg@public.gmane.org> wrote:
>>> I have been evaluating the excellent and super fast Similarity
>>> Analyser
>>> by Red Hill Consulting to generate a dupplicated lines reports from
>>> Rails 1.2.0 RC2 source code (excluding the tests).
>>>
>>> On the 10th of January 2007, Rails 1.2.0 RC2 has 4125 duplicate
>>> lines
>>> in 793 blocks in 231 files
>>>
>>>     * actionmailer has 584 duplicate lines in 107 blocks in 20
files
>>>     * actionpack has 718 duplicate lines in 154 blocks in 58 files
>>>     * actionwebservice has 241 duplicate lines in 51 blocks in 21
>>> files
>>>     * actionrecord has 1529 duplicate lines in 301 blocks in 45
>>> files
>>>     * activesupport has 418 duplicate lines in 78 blocks in 44
files
>>>     * railties has 635 duplicate lines in 102 blocks in 43 files
>>>
>>> Detailled reports on
>>> http://21croissants.blogspot.com/2007/01/rails-120-rc2-
>>> dupplicated-lines-simian.html
>>>
>>> Now the debate is opened about what to do with these reports !!!
>>>
>>> Jean-Michel
>> Whatever happens, I wouldn''t expect it to happen before the
>> release of
>> 1.2.  Submit a bug report with the full report and target it to 2.0.
>> Also, a post to rails-core about this would probably be a good idea,
>> though you might want to wait until 1.2 is out.
>
> Looking at the bottom lines of the reports, it appears that Simian
> regards Rails as being about 90% DRY. Not at all bad.
>
> Now if I were in the core team, I would not appreciate having a
> load of statistics dumped into Trac and called a defect. Output
> from tools like Simian requires intelligent interpretation.
>
> I suggest that Jean-Michel should prioritise the reported
> duplications by the expected saving if the duplicated code were to
> be refactored out - roughly (N-1)*(M-1) where N is the number of
> duplicated lines and M is the number of occurrences. The N-1 is
> because a call to the extracted method will still be required at
> each place where the code is duplicated, and the M-1 is because M
> occurrences will be reduced to 1.
>
> Then, in priority order, he should look at each candidate for
> refactoring and try to come up with an intention-revealing name for
> the extracted method.
>
> The core team might look kindly on patches which:
>
> - reduce code size
>
> - increase understandability of the code
>
> - don''t break any tests.
>
> Just my tuppence worth :-)
>
>   Justin Forder

But if you actually go to the "duplicated" source lines, you find
many of the 4-line duplicates to be

1:  end
2:
3:  def something
4:    @something

in different classes or subclasses.  My resonse to "what to do with
these reports" is to ignore them.  Unless the threshold is made >= 6
(instead of 4), or the tool was sophisticated enough to discount
lines that are blank or contain only "end" (or "begin" or
"rescue" or
"else", etc.), the report is too bloated to be very helpful.  It
reminds me of debates about whether counting LOC (lines of code) in C
should include lines having only "{" or "}".

-Rob

Rob Biedenharn		http://agileconsultingllc.com
Rob-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org