[ANN] flog 1.1.0 Released

[Ryan Davis]

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>

 

[Chad Perrin]

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?

 

[Thomas Metge]

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.




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

 

[Thomas Metge]

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

 

[Eric Hodel]

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.

 

[Sam Pierson]

To normalize the "final score" shouldn't it be divided by the number of
lines of code to indicate an overall complexity metric?
-Sam.

 

[Ryan Davis]

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

 

[Ryan Davis]

the flog total score is an overall complexity metric.

dividing.by.loc.is.bad ==

dividing.
by.
loc.
is.
bad

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: ==

 

[hadley wickham]

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

 

[Ryan Davis]

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.

Which tells you what? In what way is that useful?

 

[Chad Perrin]

Which tells you what? In what way is that useful?

It tells you that you aren't trying to cram too many things into a single
line of code. (It also might tell you that you're taking the idea of
making each discrete line simple a little too far.) In addition to
keeping the program as simple and clean as possible (without sacrificing
what the program needs), it's also generally important to avoid making
individual lines too complex.

On the other hand, I don't think an average line complexity is all that
useful a metric, unless your code is so severely over-complex per line
that it shows an outrageously high average complexity -- in which case,
it should be obvious to you anyway (and if it isn't, you may want to give
up programming for a career in bureaucratic middle management in the
public sector instead). Line complexity really needs to be judged on a
case-by-case basis. I can understand the desire to get some kind of line
complexity measure, though, even if I think an average per se is not the
best way to do it.