-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: node visitors for style metrics #206
Comments
@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
<#206 (comment)>, 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:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
The text was updated successfully, but these errors were encountered: