4 ms·
Just to add to the blog post a bit: those flog scores interpretation are ONLY valid if you use them on a per-method basis... on a per-file or per-project level
by zenspider 18y ago
Just to add to the blog post a bit:
those flog scores interpretation are ONLY valid if you use them on a per-method basis... on a per-file or per-project level they're completely invalid.
For example:
% pwd; flog -n -m lib | head
/Users/ryan/Work/p4/zss/src/ruby_parser/dev/
Total Flog = 5284.4 (12.2 +/- 2852.7 flog / method)
RubyLexer#yylex: (1076.9)
RubyLexer#tokadd_string: (146.8)
RubyLexer#read_escape: (130.5)
RubyLexer#heredoc: (118.3)
RubyLexer#heredoc_identifier: (89.6)
RubyParser#literal_concat: (81.2)
RubyParser#assignable: (65.2)
RubyLexer#parse_quote: (63.4)
There is little I can do at this time to clean up the monstrous yylex, but tokadd_string, read_escape, and heredoc are all too big and need some attention to clean them up. Everything else is, relative to those scores, reasonable and can be ignored at this time.
I am still chuckling that he recommends capistrano right after pushing tools to fight complexity...
- ivey 18y agoFor the 80% case, cap works fine. It's when you need to do stuff in that last 20% that you have real trouble.
- zenspider 18y agoI was in the 80% case when I wrote vlad. cap does NOT work fine. It is a steaming pile of intertwined crap... imhfo. We got the 80% usage case of vlad covered in about a 3rd() of the code that cap required. ) actually π. In the release notes for vlad 1.1: "The flog ratio between capistrano+deps / vlad+deps is pi (or, damn close)!". Line numbers correlated fairly close iirc.