Open dollodart opened 3 years ago
@dollodart Hi David, I missed this message and I see it only now. I'd say such a visitor would fit within the scope of the project, as it provides metrics similar to the Halstead complexity or the maintainability index.
I'd be happy to review a PR, it just needs to include tests and follow the code style of the rest of the project. Let me know if you are interested in working on it.
Hi Michele,
I revised the project after you sent this message and think I could make something analogous to the HalsteadVisitor class. The main problem I see is that the recursive class instantiation method for special node types, like in HalsteadVisitor.visit_FunctionDef, is slow. In particular, the merging process is slow (the instantiation and the walking are not, as I tested by separating them). The HalsteadVisitor has a relatively simple merge procedure that is fast in the tests:
for child in node.body:
visitor = HalsteadVisitor.from_ast(child, context=node.name) #
instantiation
# start merging
self.operators += visitor.operators
self.operands += visitor.operands
self.operators_seen.update(visitor.operators_seen)
self.operands_seen.update(visitor.operands_seen)
func_visitor.operators += visitor.operators
func_visitor.operands += visitor.operands
func_visitor.operators_seen.update(visitor.operators_seen)
func_visitor.operands_seen.update(visitor.operands_seen)
# end merging
I don't know how to make the Counter merging faster yet (it uses getattr and setattr calls because of the large number of attributes). I'll let you know if and when this develops.
On Wed, Feb 23, 2022 at 2:42 PM Michele Lacchia @.***> wrote:
@dollodart https://github.com/dollodart Hi David, I missed this message and I see it only now. I'd say such a visitor would fit within the scope of the project, as it provides metrics similar to the Halstead complexity or the maintainability index.
I'd be happy to review a PR, it just needs to include tests and follow the code style of the rest of the project. Let me know if you are interested in working on it.
— Reply to this email directly, view it on GitHub https://github.com/rubik/radon/issues/206#issuecomment-1049198617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVG5AQ6BQ2YNBSYC7FNX7LU4VBEPANCNFSM4UXLUNOQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
For reference, please see https://github.com/dollodart/pymetrics. This amounts to adding new node visitors and is like issue #163. Since complexity metrics are used in linters which have the main purpose enforcing style rules you may want style metrics. These analytics could be useful in project-specific guidelines up to PEPs where you are trying to assess what stylistic rules most users want (nominally which are best).
Is this within the scope of this project and would a PR having node visitors like in the link for pymetrics be accepted?