Well, it would be nice to have such an elementary syntax checker. However, as you have probably seen already in every spot where Qlik tries to accomplish just that (expression editor, script editor etc.), there are various reasons why it is close to impossible to do better than what we have at the moment AFAIK these are such reasons:
- Statement order vs Code execution order: imagine that the table without MAPPING prefix is used for something else, and inbetween that MAPPING-less LOAD and the subsequent use of an ApplyMap, there is a CALL to a SUB that does define the mapping table. How would the syntax checker figure out whether there is an error at all?
- $-sign substitution: this is the nemesis of all analysis tools and efforts. $-sign substitution forces you to simulate/execute all preceding statements before you can actually analyse a $-substitution loaded statement at all.
- The world of run-time errors vs the separate world of syntax errors. Actually specifying a mapping table name that is nowhere to be seen until then is not a syntax error by itself. Up until recently, it wasn't considered an error at all. In the most recent QV12 versions, Qlik has intelligently classified it as an run-time error, which makes early discovery at least a little bit more probable. But you'll still have to run your code before the missing table is detected.
- Etc...
One solace: there are entirely different remedies to make script coding more efficient and recover some of the lost time. Marcus has already mentioned one (shorten your development cycle and you will discover your bugs easier and faster). Another one is the modular approach to programming: write your code in (almost) self-contained units and test them on their own using input/output specs and data. You can use the SUB...END SUB container for that. And a third one is really a more process-oriented approach: use code reviews to detect the things you don't see and at the same time improve the implementation of functional specs. There is a famous saying in the OSS world: "the more eyeballs, the shallower the bugs". These techniques offer no guarantee that you will find every snag, bug or omission before you first run your code, while some of them are better suited for teams of two or more people, and the popularity of code reviews may go up&down every so often... But they certainly help It you're concerned about the frustration and cyclic wall bumping and head hitting during typical QlikView development sessions.
Best,
Peter
.png "Luminary Alumni"){kind=icon}
