You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an extension to the suggestion in covermymeds/issues/4, perhaps we should flag up ivars used in methods of any module.
This would unfortunately add some false positives as modules may be included in classes, making instance methods and hence would be using instance variables rather than class instance variables.
They could be individually checked by the user and ignored with a rubocop:disable comment. Or perhaps this should be an option to the InstanceVariableInClassMethod, which may be set depending on how prevalent extending modules is in the user's codebase.
Concerns I would like to catch would be:
moduleModdefsome_method(something)@params=somethingendendmoduleExtModextendModendclassExtClassextendModendExtMod.some_method(something)# sets a class instance variable on ExtModExtClass.some_method(something)# sets a class instance variable on ExtClass
False positives that would be difficult / impossible to rule out in a static analysis:
moduleModdefsome_method(something)@params=somethingendendclassIncluderincludeModendinstance=Includer.newinstance.some_method(something)# sets an instance variable on instance
The text was updated successfully, but these errors were encountered:
this would cause more false positives than it would correct catches don't you think? people include and prepend modules way more often than they extend them except for the ClassMethods convention, at least from my experience.
is there a way code is capable of being analyzed for if it is being used as an extension?
This is a recreation of covermymeds/issues/22 opened by @biinari on Jun 22, 2020.
As an extension to the suggestion in covermymeds/issues/4, perhaps we should flag up ivars used in methods of any module.
This would unfortunately add some false positives as modules may be included in classes, making instance methods and hence would be using instance variables rather than class instance variables.
They could be individually checked by the user and ignored with a
rubocop:disable
comment. Or perhaps this should be an option to theInstanceVariableInClassMethod
, which may be set depending on how prevalent extending modules is in the user's codebase.Concerns I would like to catch would be:
False positives that would be difficult / impossible to rule out in a static analysis:
The text was updated successfully, but these errors were encountered: