Hi @Evgeny Shvarov,

I, and I think Enrico too, was talking not only of the 16 rules you've selected, but the 100+ rules that are in the product if you buy it.

As far as I can see, the 16 rules are mostly about bugs which should easily be found by simple testing.

One of the biggest problems I have with OQ is that it doesn't expand macros, which gives a lot of false positives.
For instance $$$ReturnError("Illegal argument") isn't regarded as a Return, which is in the macro definition.
The same for $$$Yes, $$$True, etc aren't recognized as legal boolean values.

Silly rules that state that you should use certain syntax formats, such as parenthesis around conditions, because otherwise it is hard to comprehend for people coming from other programming languages.

I don't have the time to go though all rules but I will illustrate with one.

Rule ID:objectscriptquality:OS0078

Incompatible argument type in a method

The title is wrong, it should be "in a method call"

The argument passed must be of the type expected by the method. When no type is defined for a parameter, a %String argument is expected.

The first part of the sentence makes sense, the second is not true for Objectscript. If no type is specified the argument can be of any type.
If this is something you want is another issue.

Sometimes you want an argument to be able to be of different types.
For instance if an argument is of type %Stream, you might want to allow a simple string as a value too.

In general I would say this is not a rule that would enhance the quality of the code.

Then the rule explanation is simply wrong.

In following code, method DoWork2 expects to receive %Numeric as argument and DoWork3 expects to receive %DateTime as argument, but in both cases receive Sample.Person and will raise a "PARAMETER error" message on runtime.

A "PARAMETER error" only occurs when supplying too many arguments in the call and has got nothing to do with the datatypes of those arguments. Besides; running the example code gives no error at all.

Then the example code has several issues, which I won't discuss right now.

I wouldn't know why setting up ECP isn't easy.
Super easy by the Management Portal, but it can also be scripted.
For 'useful' I'd say: just skim through your globals and copy or merge whatever you need.

Hi @Enrico Parisi,
I was going to say "I wasn't aware of that previous discussion", but I saw that I actually contributed to it :-(
Indeed, since February nothing has changed.
We are all busy and apparently didn't have had the time to make our own attributions.
For me, I wouldn't know how to define a CQ rule, SonarCube is Java based AFAIK and I'm not a Java tiger.
It would be great if ISC would set up a GitHub repository with rules to which we can contribute.
I am not involved in the code base that was obliged to use CQ so it doesn't bother me directly anymore.
But SonarCube has some status and if a customer demands that the code base adheres to the rules of such a tool, you're in trouble. Perfectly working code (for years) suddenly has many major and critical 'errors' and you have to explain why that is.
I think no tool is better than a bad tool.