Introduce absolute threshold configuration

[maxjacobson]

I want to know about the complex methods in my code, so I can make my code easier to test and understand.

Flog can tell me about the complexity of my methods by scoring them. It can either:

1. tell me the score of all of my methods
   • pro: interesting information!
   • con: not appropriate to create a CC issue for each method, because an issue suggests there is a problem
2. tell me the score of just my most complex methods based on percentile
   • pro: makes sense in a CLI context; I can focus on improving the most complex methods, and not worry about the less complex stuff until I've worked through the higher-priority problems
   • con: different from other CC engines, which emit an issue for every problem they encounter on every run. They can be configured with thresholds, but the thresholds usually not percentile-based. This can be confusing, because you may fix an issue in one file, which leads to another issue being created in another file, as the less complex methods move higher in the ranking of method complexity and cross the threshold.

Proposal: let's pick an absolute number to be the default complexity threshold (20ish seems good to me), and only emit issues for a method when its complexity is above that threshold. We should make this value configurable. I propose managing this in the engine, although you may prefer pushing the concept into flog itself for the sake of keeping the engine a thin wrapper around the tool.

@zenspider I'd like to start working on this, but I know it's a little different from what we discussed (just making "all: true" the default) so I'd like to give you a chance to think about it and let me know what you think.

[RoryO]

Forgive me if I'm not understanding this correctly. If there is not a hard complexity threshold number with the current configuration then there will always be 39% of the methods marked as complex?
For example, If I have a project with a medial flog score of a reasonable 8 and a low standard deviation there can be complex methods that will be scored with a complexity of 10. That's not very useful.

Further without a floor threshold this introduces a sliding window problem as discussed. A successful refactoring will drive the median lower and introduce new methods into the new lower bounds of percentile window. I have seen this happen in our own project. By making methods simpler or deleting entire classes unrelated methods are now appearing in analysis as complex. Unless I'm missing something fundamental a floor value is necessary.

I have no idea how to derive that number without just pulling something random out. @maxjacobson CodeClimate has a volume of information. Would it be possible to derive a decent floor score from of high scoring, low complexity projects?

[maxjacobson]

@RoryO "sliding window" is a good way to put it. I agree we should change this, and I've opened this PR: #7

CodeClimate has a volume of information. Would it be possible to derive a decent floor score from of high scoring, low complexity projects?

Using data to pick a number sounds more scientific than what I did (look at our own app's scores and pick a threshold after which methods "felt" too complex for my taste). :)