Halstead Operators

[pahlers]

During my study of the working of TypeScript and Halstead metrics I found your inspiring work.

I wrote a small application to calculate metrics my self. With the help of your HalsteadCountableNode code I was able to find the correct SyntaxKind numbers to use to calculate the metrics.

Of course I compared the results of our applications and it's a bit odd. The operands are exact the same. But the operators are way off.

Given the following code.

function test(item) {
    if (item <= 3) {
        const test = item + 5 * 123;

        console.log('hi', test);

    } else {
        console.error('oops');
    }
}

I got 15 distinct operators

• function,
• (,
• ),
• {,
• if,
• <=,
• const,
• =,
• +,
• *,
• ;,
• .,
• ,,
• } and
• else

Your code is returning 3 distinct operators

• <=,
• + and
• *

Obvious I'm doing something wrong. My isOperator is in someway leaking operators. It looks like you code doing some pre-filtering for the operators to fix this.

I found some information (page 4) about Helstead metrics which tells

Operators:
• traditional (+,++, >), keywords (return, if, continue)

Please, can you explain to me

1. Which operators do you use?
2. Where is the pre-filtering done?
3. Why did you choose to use a pre-filter instead of solving this in the isOperator function?
4. What is you opinion about the information?

Kind regard,
Peter

[ytetsuro]

Thanks comment.
Sorry for the late reply.

Which operators do you use?

PHP is following.

https://github.com/ytetsuro/sabik/blob/develop/src/Language/PHP/HalsteadCountableNode.ts#L35-L122

TypeScript is following.

https://github.com/ytetsuro/sabik/blob/develop/src/Language/TypeScript/HalsteadCountableNode.ts#L18-L20
https://github.com/ytetsuro/sabik/blob/develop/src/Language/TypeScript/HalsteadCountableNode.ts#L30-L36

Where is the pre-filtering done?

Excuse me.
I don't know which Pre-filter you are referring to.
In sabik, we are looking for halstead metrics on a per-method or per-function basis.
So, we ask for halstead metrics using only the code in the method or function.
That is, blocks of function or function and declaration definitions ({, (, etc.) are not included.

The filtering is done below.

https://github.com/ytetsuro/sabik/blob/develop/src/Analyzer/FromASTNode/MethodAnalyzer.ts#L16

Why did you choose to use a pre-filter instead of solving this in the isOperator function?

We believe that it is better to measure only within METHOD based on the following.

http://www.virtualmachinery.com/sidebar2.htm

All of the Halstead metrics can be calculated at the method level. At higher level care needs to be taken to ensure that they are calculated properly. This is because it does not make sense to accumulate the numbers of unique operators and operands. However it does make sense to some accumulate values that are based on these as long as the calculations from which these are derived are only performed at method level.

What is you opinion about the information?

From what I see below, sabik is wrong and needs to be corrected!
Thanks!

A simple example of an operator is something that carries out an operation using zero or more operands. An operand is something that may participate in an interaction with zero or more operators.

Most people here would be happy to describe = and + as operators. Similarly X, 1 and 2 can probably be safely viewed as operands. This leaves us with ‘int’ and ‘ ;’. We could view ‘;’ as an operator as it performs a function on the line of code – it illustrates that the line is ended. Or we could ignore it, justifying our choice by saying that it is simply a punctuation mark. ‘int’ is a qualifier of the variable X – is it then a part of the definition of the identifier (making it an operand) or does it change the nature of the identifier and therefore acting more like an operator. Even with a small simple example like this you can see how many possible interpretations there could be.

We’ve only partly answered our questions at this point but we need to take a break to look at what Halstead was trying to measure. The names of his metrics give us clues as to what he was aiming for. The three most primitive Halstead metrics are Length, Vocabulary and Difficulty. So we see an immediate parallel between Halsteads view of code and a readers view of a piece of text (e.g. a book). When we pick up a book we can glance through it and we will get an immediate sense of how much effort we are going to have to put into understanding this book. A glance at the last page tells us how many pages we have to read, looking at a couple of pages will give us a sense of how difficult the book is to read – the number of technical terms, sentence and paragraph length. With a book we might also assess the ease of understanding by looking at the number of illustrative diagrams – but that’s not an issue with code.