Well actually I find most of the rules subjective without good reasons stated.
( ... more detailed response for 'codeheads' ... click to expand ... )
I’ve got 40 years of experience so I don’t use it myself. I don’t even use a debugger as Ruby itself outputs very informational exception messages. A good editor with AutoComplete is enough for me.
Don’t get me wrong I do take some of the advice from the bbatsov rules posted at GitHub, but many are just nickpicking.
Most of the time, no one else but the author is going to read the code. So only errors that violate EW rules of namespacing (interference with other extensions) or that modify core Ruby or API modules and Classes directly need to be flagged and corrected.
It is a whole other “ballgame” if the code is a group or community project.
Complexity
So while coding, if even I am having to spend extra brainpower keeping track of what a complex method is doing, I feel then that it’s time to break it up into multiple methods. The “offenses” that Rubocop spits out can be a good flag for the author to take a look at such methods. As code authors we often have to return later to fix a bug or add improvements and then we spend extra time relearning was it was were were thinking whilst writing complex methods. So smaller methods and good commenting in the code will help you later.
I think that a score of 7 or 8 will spit out a warning. Only using rubocop for awhile and coding with the SketchUp API for awhile can give you insight into whether the trigger level are too high or too low.
ParameterLists
For SketchUp coding there are many API methods that use a lot of keyword (named) arguments. The UI dialog class constructors or file export methods come to mind.
If you are subclassing, you may not have the option of omitting these. I would suggest setting CountKeywordArgs: false at the least. You can also define a separate limit for optional arguments via MaxOptionalParameters: to allow for more flexibility in method signatures that rely heavily on default values.
But it is true that long method parameter lists become unwieldly and is a sign that a method is doing too much. I’ve done what is suggested in the past of breaking the method up into smaller methods, or collecting the data arguments into a hash and passing that in then perhaps having a few named control arguments follow the hash.
I think the default limit is 5, but in practice if the method signature line approaches 80 characters, my mind thinks that is too much, especially for methods other coders would use.
But if it is only my code and used within a single extension, I have to decide whether the benefit outweighs the cost of constructing a hash to make the call and then deconstructing the hash within method to get variables. That construct/deconstruct is going to take time.
If the code is within an instance, you have the option of using @instance_vars instead of passing state around between methods. I know there are those who frown upon this, but it is what instance variables were designed for. (For the record, a module is an instance of class Module and can itself have instance methods.)
Also, Ruby passes mutable objects [Arrays and Hashes] as references anyway, so you can mutate the original from inside the receiving method. But immutable objects can also be used as local variables inside the method and be reassigned to local values. (It depends upon what method is used.)
So if the arguments are shared anyway, why not take advantage of instance variables and make your life easier?
The debate is going to go like: “The parameter list is a declaration of what values the method uses or may mutate.” My retort would be … Use method descriptions and comments for this.
