You still need to know what Membership represents, that it has a IsExpired field, that that is a Boolean, and what it means.
Most of it is in the business domain, though.
You may want to start at https://en.wikipedia.org/wiki/Software_metric, which has links to methods both for estimating complexity before a line of code is written and for estimating complexity of existing code. For the latter, examples are:
AFAIK most of them estimate the complexity of multiple lines of code/functions/entire programs.
I don’t think there is agreement as to the usefulness of this, and if so, which method is the best, or whether it’s possible to measure software complexity at all (for the latter, I think everybody’s gut feeling says “yes”, but I don’t think every person would even place different program fragments in the same order of complexity (example: foo.map.filter(…) versus a for loop with a nested if. Which one is deemed simpler depends on one’s pre-existing knowledge)
I also think we can only estimate program complexity roughly, and wouldn’t go as far as calling anything a metric.
Halstead complexity is about the call graph: the number of possible paths through the code.
Cyclomatic complexity is about the number of 'units of syntax' in the code, which I think is closer to what OP is asking. It uses the terms "operator" and "operand".
In the terminology typically used around parsing code, one way to measure complexity is the number of tokens. In the Halstead terminology that would be both operators and operands. https://en.wikipedia.org/wiki/Lexical_token
Comments
In
You still need to know what Membership represents, that it has a IsExpired field, that that is a Boolean, and what it means.Most of it is in the business domain, though.
You may want to start at https://en.wikipedia.org/wiki/Software_metric, which has links to methods both for estimating complexity before a line of code is written and for estimating complexity of existing code. For the latter, examples are:
AFAIK most of them estimate the complexity of multiple lines of code/functions/entire programs.I don’t think there is agreement as to the usefulness of this, and if so, which method is the best, or whether it’s possible to measure software complexity at all (for the latter, I think everybody’s gut feeling says “yes”, but I don’t think every person would even place different program fragments in the same order of complexity (example: foo.map.filter(…) versus a for loop with a nested if. Which one is deemed simpler depends on one’s pre-existing knowledge)
I also think we can only estimate program complexity roughly, and wouldn’t go as far as calling anything a metric.
Clickable:
https://en.wikipedia.org/wiki/Halstead_complexity_measures
https://en.wikipedia.org/wiki/Cyclomatic_complexity
Halstead complexity is about the call graph: the number of possible paths through the code.
Cyclomatic complexity is about the number of 'units of syntax' in the code, which I think is closer to what OP is asking. It uses the terms "operator" and "operand".
In the terminology typically used around parsing code, one way to measure complexity is the number of tokens. In the Halstead terminology that would be both operators and operands. https://en.wikipedia.org/wiki/Lexical_token
Another is the number of symbols. The Wikipedia article is a little abstract: https://en.wikipedia.org/wiki/Symbol_(programming) but in the Halstead terminology would be operands.
(The following is a little hand-wavy because the definition of "symbol" varies.)
Tokens, space delimited: if ( obj . index == 0 && ( f_mode > 3 || state [ 1 ] != null ) )
Symbols: if obj index f_mode state null
versus
Tokens: if ( Membership . IsExpired )
Symbols: if Membership IsExpired