flog version 1.1.0 has been released!
* <http://ruby.sadi.st/>
* <http://rubyforge.org/projects/seattlerb>
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
Flog#report: (21)
4: puts
2: sort_by
...
Changes:
* 3 major enhancements:
* Added assignments and branches and a lot of other stuff. rad.
* Added process_iter section for DSL style blocks (rake tasks etc).
* Made Flog usable as a library.
* 12 minor enhancements:
* Added -a flag to turn off threshold culling for other tools.
* Added -s for summarizing the score.
* Added -v feedback to know what file you're flogging.
* Added branching penalty so tons of nested conditionals get beat down.
* Added send (3).
* Capture and ignore SyntaxErrors from template/generator code. Stupid DHH.
* Report can now take an IO object.
* block_args now penalizes all non-benign forms of block_pass.
* Added usage to bin/flog. Moved -I processing to bin/flog.
* Added unpack.rb and update_scores.rb at base level (not installed)
* Added scoring for block_pass.
* Converted totals to use distance formula on ABC's.
* 3 bug fixes:
* Ran flog on every latest gem available. Found a bunch of problems.
* Use a stack for both class/module and method accounting.
* block_args weren't processing the arg
* <http://ruby.sadi.st/>
* <http://rubyforge.org/projects/seattlerb>
flog version 1.1.0 has been released!
* <http://ruby.sadi.st/>
* <http://rubyforge.org/projects/seattlerb>
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?
···
On Tue, Aug 21, 2007 at 05:05:33PM +0900, Ryan Davis wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);
Thomas Metge wrote:
Chad Perrin wrote:
flog version 1.1.0 has been released!
* <http://ruby.sadi.st/>
* <http://rubyforge.org/projects/seattlerb>
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. i.e. (from sample on website):
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
in here, it would be worth removing the "eval" statement... which i can understand. it'd be interesting to see the weighting scale used though. i'll have to take a look at the source...
nice job on flog!
tom
···
On Tue, Aug 21, 2007 at 05:05:33PM +0900, Ryan Davis wrote:
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.
···
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!
* <http://ruby.sadi.st/>
* <http://rubyforge.org/projects/seattlerb>
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.
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars
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!
>>>>
>>>> * <http://ruby.sadi.st/>
>>>> * <http://rubyforge.org/projects/seattlerb>
>>>>
>>>> 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
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" <sam@ombwa.com> 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!
* <http://ruby.sadi.st/>
* <http://rubyforge.org/projects/seattlerb>
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
the flog total score is an overall complexity metric.
dividing.by.loc.is.bad ==
dividing.
by.
loc.
is.
bad
···
On Aug 24, 2007, at 07:52 , 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?
Just in case the above is unclear... it is completely valid ruby syntax:
% flog
dividing.by.loc.is.bad ==
dividing.
by.
loc.
is.
bad
^d
Total score = 17.0
main#none: (17.0)
4.0: dividing
3.6: by
3.2: loc
2.8: is
2.4: bad
1.0: ==
···
On Aug 25, 2007, at 04:24 , Ryan Davis wrote:
On Aug 24, 2007, at 07:52 , 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?
the flog total score is an overall complexity metric.
dividing.by.loc.is.bad ==
dividing.
by.
loc.
is.
bad
I don't think that invalidates the usefulness of an complexity per LOC
metric. It's measuring something a little different, which still
might be useful. Clearly the two sides of the statement have equal
complexity, but the RHS has lower complexity per LOC.
Hadley
···
On 8/25/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Aug 24, 2007, at 07:52 , 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?
the flog total score is an overall complexity metric.
dividing.by.loc.is.bad ==
dividing.
by.
loc.
is.
bad
--
http://had.co.nz/