This is not a bug report but more of a checklist (~ roadmap) that'll get updated with status of items already present, and with new items as the codebase gets refactored.
It'll additionally serve as a future reference to what's considered optimal for the WABuR library.
Initialize a Utility Module WAB::Utils to handle behavior across WAB classes [#10]
Abstract frequently used methods to the Utility module [#52], [#77]
Improve readability in impl/data.rb by replacing if..elsif..else with case..when expressions where the check is one variable. [#13]
Use clause statements to replace conditional branches, where fit [#90]
Replace global variables with instance_variables or constants Improve readability by abstracting nested if..elsif..else to private methods Replace Yoda conditions where conventional conditions would be more optimal
Prefer single-quotes consistently unless double-quotes are required for interpolation, special characters [#92]
assign to a variable outside the conditional block [#89]
Not much for utils right now but I'm sure that will change as we go along. Good to start it now.
Nothing wrong with nested conditions. I don’t think the fact that conditionals are nested is the right metric for making a separate function. I’d prefer either function gets too large too fit on a page (50-ish lines) or is used in more than one place as the reason for breaking up a function.
I like Yoda style. I see no reason for force a particular order on items being compared. Once you start down that rat hole you get into argument about which side is more constant or which is better. I don't want to force any order on people and don't want it forced on me either.
I generally prefer single quotes as well when possible. Don't mind that cleanup at all.
Like any function, for the evaluation of foo == bar both arguments need to be evaluated and will. It doesn't matter what order. In the example above TrueClass, as an example is a constant so there is no eval per say other than to use the value. Since value_class is a local variable it is not evaluated either and is most likely in a register on the stack. So maybe a bad example since the only evaluation is the ==.
I thought this is where you were going to use a case statement instead. Yes?
Since value_class is a local variable it is not evaluated either and is most likely in a register on the stack.
I stand corrected regarding this notion. Should've realized myself that local variables are treated the same as constants in an expression but it would've been evaluated if value_class was instead an instance_method
I thought this is where you were going to use a case statement instead
Yep, this and similar long ones are being considered for a case expression, too.. but in a separate PR..