launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Feb 8, 2012 at 3:14 AM, Benji York <benji.york@xxxxxxxxxxxxx> wrote:
> On Tue, Feb 7, 2012 at 8:03 AM, Richard Harding
> <rick.harding@xxxxxxxxxxxxx> wrote:
>> On Tue, 07 Feb 2012, Robert Collins wrote:
>>
>>> So - who would be happy (and who would not) with a LOC rule like the one above?
>>>
>>> -Rob
>>
>> So I'm officially in the "wait and see" boat on this. It strikes me that a
>> lot of our overall goals of modularity, components, etc are very likely to
>> increase LoC just because it's the nature of splitting things. I don't have
>> any hard numbers though, so perhaps this is a logical fallacy I've got in
>> my head and I'd be curious to see how it works out.
>
> We could use cyclomatic complexity instead of LOC, but we would need
> slightly more tooling to support that.

Patches accepted ;). Cyclomatic complexity is fascinating. I think it
is great for identify test permutations, less so for measuring
'goodness'. However, running a few patches that we know are good/bad
past a counter and seeing what comes out would be pretty darn
interesting.

>> I do think that just having this as a code review bullet point is good
>> though. It's much easier to have the discussion during a code review with
>> the current policy than it might have been a little bit ago.
>
> If we adopt a policy like the one under discussion, it should certainly
> go into the "things discussed during a review" bucket.  MPs can require
> sloccount output just as they require lint details today.

Using the diff as proposed is an even cheaper metric; its a lie, but
perhaps good enough to start with.

-Rob