Skip to content
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

Too few operators recognised for Halstead calculations #160

Open
JamesCC opened this issue Nov 25, 2018 · 1 comment
Open

Too few operators recognised for Halstead calculations #160

JamesCC opened this issue Nov 25, 2018 · 1 comment

Comments

@JamesCC
Copy link

JamesCC commented Nov 25, 2018

It is appreciated that one of Halstead's weaknesses is a lack of agreement on what is and isn't an operator. However, the stats look very kind at the moment, suggesting operators are being missed. It would be good to a have a declaration of operators that are recognised on the docs page.

It seems at the moment detected operators (you are welcome to correct me if I'm wrong) are:

  • Binary Operator
  • Boolean Operator
  • Unary Operators (such as ones complement, not, lone minus sign)
  • Comparison Operators
  • Augmented assign (e.g. a+=1)

And these are not recognised:

  • Assignment
  • Function/Method calls
  • Conversions such as str, dict, list, bytes, ...
  • If statements - whilst comparisons are, in the case if var: var would be ignore as an operand, and if does not count as an operator
  • List and Set Comprehensions are completely ignored

IMHO these should all impact the Halstead calculations - but I'm guessing its difficult to get the info from the "ast" module?

@rdbliss
Copy link
Contributor

rdbliss commented Nov 27, 2018

I agree that most of these should be recognized. Halstead even refers to the "assignment operator" a few times in The Elements of Software Science, using it to compute some ideal metrics like potential volume.

Some of these seem simple to add. A quick glance at the ast docs shows that assignment, functional call, and conditional nodes are all there. Type conversions parse as functions under the hood, so those would be included. List comprehensions are also there, and could probably be handled recursively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants