Flog 1.1.0 Released

Ruby
1

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

 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

2

On Tue, Aug 21, 2007 at 05:05:33PM +0900, Ryan D. 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?

3

Chad P. wrote:

% ./bin/flog bin/flog
     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

4

Thomas Metge wrote:

Flog#report: (21)

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

5

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

6

On Aug 23, 2007, at 13:33, Thomas Metge wrote:

report. The higher the score, the more pain the code is in.

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.

7

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 :slight_smile: It’s helped me pin down some areas of improvement and
optimization.

tom

8

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

9

On 8/25/07, Ryan D. [email protected] wrote:

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

10

On Aug 25, 2007, at 04:24 , Ryan D. wrote:

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

11

On Aug 26, 2007, at 13:43 , hadley wickham wrote:

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?

12

On Tue, Aug 28, 2007 at 11:20:43AM +0900, Ryan D. wrote:

On Aug 26, 2007, at 13:43 , hadley wickham wrote:

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?

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.