On Wed, Feb 8, 2012 at 3:14 AM, Benji York <benji.y...@canonical.com> wrote: > On Tue, Feb 7, 2012 at 8:03 AM, Richard Harding > <rick.hard...@canonical.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
