CachéQuality: two new rules

Hello community!

Two new rules have been implemented:

OS0061: unsafe namespace switch

This rule detects when the body of a method contains two or more of the following statements:

  • set $namespace = something, or
  • znspace something.

If this is the case, it then checks whether there is a new $namespace prior to those two declarations; if not, it raises a warning.

List of issues currently found here:|rules=cachequality%3AOS0061|resolved=false

OS0062: confusing identifiers

This rule detects whether either of a method argument, or a local variable, differ only by case (for instance, foo and Foo). It detects all of "conflicting" arguments (after all, you can declare method m(a, A)), arguments vs vars, or vars. List of issues currently found here:|rules=cachequality%3AOS0062|resolved=false

More rules to come :)


Why is this showing in Developer Community Feedback?

This is my choice.

The goal is, after all, to find issues in ObjectScript code; as such, developer feedback on issues are very important :)

Unless I have misunderstood the goal of this forum completely?

Francis, I think the idea of the "Developer Community Feedback" community/group is to discuss the behaviour of this website software.

I think your posting belongs better in the "Caché" community/group because that is the base product from InterSystems in which COS is implemented, and upon which Ensemble, HealthShare and DeepSee (which each have a separate community/group) are built.

Consider adding links to cache documentation from the page that describes the issue, we now have version agnostic urls even. For example this issue could use a link to documentation.


Another question is: what's wrong with postconditionals? They exist not only in caché objectscript and in fact very useful as they allow elimination of all 3 lines blocks with one if condition and one action to execute if if is true. Can I disable an issue type for a project?

Hello Eduard,

I was not aware of version agnostic URLs. I will use them, thanks for the link! And yes indeed, I know that the documentation is lacking in some areas. And in fact I have a branch dedicated to issue documentation updates... Time to update and merge, I guess :)

As to postconditionals, well, I put myself in the place of someone which is new to the language: his background will more than probably be with languages with all the "classic" branch keywords (if, else, while, do...); making it so that the code is more readable is always a win! And no, shorter isn't better :)

But yes, you can configure what is called quality profiles in which you select which rules you want to activate, and you can also alter their severity to fit your needs. Not only that but you can also expand the help text and change the parameters of rules which have parameters (classic example: complexity).

Oh, and by the way, there _is_ a difference between postconditionals and if (I learned that yesterday): a postconditional won't set $TEST...

If you're at the summit, remember that at 12:30pm today I'll give a short talk :) If you are there I will demonstrate, among other things, how you can set your own quality profiles.

Hope this helps!


Please note, that only legacy IF sets $TEST and it is also one line long. New IF {} (3 lines, with brackets) does not set a $TEST variable.


I was aware of the new If not setting $TEST.

And again, let me insist: shorter doesn't mean better :p