Overused identifiers - DevLog #005

I complain quite often

about another numerical framework. It defines a domain specific language, where many identifiers are overused depending on where they are used in the code. If the identifier is used at the beginning of a line, then it is most probably a flow control statement, but if used in an expression, it is either a function itself or a dimension constant. From a software architects viewpoint in my opinion that's bad design and should not be implemented.

Well, some of you might already have recognized that I'm talking about my major competitor. And some of you might also know that the editor shipped with the other numerical framework is even worse than this design decision: they 're somewhere around version 7.0.0+ and it still does not support a reasonable syntax highlighting or mouseover tooltips? Come on! That's not too difficult to implement!

However, today I faced a similar situation in my own project. I want to implement dimension constants for tables, which will automatically contain the number of lines and columns and should therefore be called lines and cols:

table(:, 1) = table(5:lines-5,cols-1);

This is quite intuitive, isn't it? The issue is, that I'm already using these two identifiers as methods and as command parameters and therefore my lexer has issues to determine, whether I want the identifier to be used as method, as parameter or as dimension constant. Due to the fact that methods start with a dot, the lexer could distinguish between methods and the other two, but not between the dimension constant and the command parameter.

The only reasonable decision was, to derive other identifiers for the dimension constant, because I do not want to break backwards compatibility, if it's avoidable. As a consequence, I named the identifiers nlines and ncols, which shall mean number of lines and number of columns. Although I'm not too pleased about this identifiers, they're a good compromise between the original identifiers and other, more lengthy names.

TLDR: I faced the situation that I was trying to overuse some of the identifiers of NumeRe. I want to avoid ambiguity, so I had to derive new names for the identifiers.