From: Tom Metge Date: 2007-08-25T00:01:53+09:00 Subject: Re: [ANN] flog 1.1.0 Released I initially thought about that too, but such a final score would potentially vary dramatically based on the complexity of the code and style of the coder- so it'd be great for scoring your own work against more of your own work, but not so great in a universal comparison. Thinking about it again, however, the final score could be derived, in part, from the number of operations evaluated, though that again would be very subjective and specific to the coder... Maybe a balance of loc and operations? Come to think of it, it would also be nice to have a summary printed for each project/directory analized, each file, each class *and* each method... It would make it much easier to tell where work is needed at a glance. Again, a very useful tool- I've already run it against several of my projects :) It's helped me pin down some areas of improvement and optimization. tom On 8/24/07 8:52 AM, "Sam Pierson" wrote: > To normalize the "final score" shouldn't it be divided by the number of > lines of code to indicate an overall complexity metric? > -Sam. > > > On Fri, 2007-08-24 at 07:20 +0900, Eric Hodel wrote: >> On Aug 23, 2007, at 13:33, Thomas Metge wrote: >>> Thomas Metge wrote: >>>> Chad Perrin wrote: >>>>> On Tue, Aug 21, 2007 at 05:05:33PM +0900, Ryan Davis wrote: >>>>> >>>>>> flog version 1.1.0 has been released! >>>>>> >>>>>> * >>>>>> * >>>>>> >>>>>> Flog reports the most tortured code in an easy to read pain >>>>>> report. The higher the score, the more pain the code is in. >>>>>> >>>>>> % ./bin/flog bin/flog >>>>>> Total score = 128.7 >>>>>> >>>>> >>>>> So . . . is that a good result, or a bad result? How do you define >>>>> "pain" in this context? Judging by the website, it looks like >>>>> uses of >>>>> eval qualify as "pain" -- which seems like an odd metric. >>>>> >>>>> >>>>> >>>>>> Flog#report: (21) >>>>>> 4: puts >>>>>> 2: sort_by >>>>>> ... >>>>>> >>>>> >>>>> So . . . is "puts" a "painful" method, then? >>>>> >>>>> >>>> >>>> good point... flog looks like a great tool, but what is a "good" >>>> score and a "bad" score? >>>> >>>> tom >>>> >>>> >>> never mind... i think i'm catching on (at last)... this is >>> extremely useful for pointing out painful parts of your code, not >>> necessarily giving a relevant final score. >> >> Here's a few examples from RubyGems trunk: >> >> Total score = 9491.3018782491 >> Server#run: (184.2) >> PristineCommand#execute: (136.1) >> Policy#verify_gem: (135.9) >> InstallCommand#execute: (123.0) >> HelpCommand#execute: (116.6) >> DependencyCommand#execute: (115.9) >> CertCommand#initialize: (110.0) >> TarOutput#open_from_io: (106.8) >> Validator#alien: (105.8) >> Gem#activate: (105.0) >> UpdateCommand#execute: (99.3) >> EnvironmentCommand#execute: (95.7) >> TarInput#initialize: (95.3) >> CleanupCommand#execute: (94.7) >> SourcesCommand#execute: (94.6) >> MirrorCommand#execute: (89.9) >> >> As you can see, #execute for various commands have high flog scores. >> I'd really prefer the commands to be nothing more than lightweight >> glue methods that simply dispatch to concrete classes to do all the >> work, as that approach maximizes reuse. >> >> -- >> Poor workers blame their tools. Good workers build better tools. The >> best workers get their tools to do the work for them. -- Syndicate Wars >> >> >> > >