You are right Robert, I should say "nothing apparently" as there is always an implicit execution to set $TEST on legacy IF (but not in new IF version).

Agree with "learning the language is and advantage", and tools should help to make an easier learning curve.

Accordingly to the different rules applied, it should be rewritten like this:

if $$$ISERR(sc) { return sc }

You can check it on the rule help provided in the same environment or here.

For now, sonarlint for VS Code does not allow to disable rules. Currently, this feature is only available on Atelier.

All the referred parameters are configurable from SonarQube, where you can define multiple Quality Profiles (it is, different sets of rules). So when you get your sonarlint connected to Sonarqube you will use the Profile definition for the particular project.

Otherwise, you are using the default settings which can be modified on a different way if many of you require it to us, but it will never fit to all projects as each one has its own particularities.

You can rise it on https://tracker.cachequality.com

I agree with "they should learn it to understand it before touching it", but we are not talking to go from Latin to Cyrillic... many people is working in Java, C#, Javascript, ... which, let's say, all of them are not just Latin but also Romanic... so after you learn a second language the third one is really easy because you know how grammatical structure works and you only need learn about semantics.

So, in our consideration and accordingly also with community users and customers that helped us to consider each rule, if the language allows a way to be more "Romanic", it's a bad practice not to use that way.

This consideration is not absolute in any way, just a recomendation.

Just to say that not all the rules are valid for all the projects/context/environments, as the development guide can differs from one company to another (even from one project to another in the same company). So the most important is to find the useful rules for each context and configure the proper profile to allow certificate the code with your own quality requirements.

First of all, you can only enable or disable rules from SonarQube, so you need your sonarlint connected to a SonarQube server to user your own set of rules. SonarLint is not ready to do that on VS Code while in Atelier can be done.

In that case, readability refers to usage of "{" and "}", as you enclose the execution of the "if" evaluation and helps to understand which instructions will be executed on true evaluation.

I will expose our considerations next, and we are opened to change it if community holds on a different suggestion, or better we can create an alternative rule to accomplish a different requirement.

You can either have many statements on one line, all of the will be executed on true evaluation, really hard to read if you have many statements:

if condition do ..firstThing() do ..secondThing()

Or you could try to write:

if condition
    do ..something()

In that case, the true evaluation will execute nothing, and the next sentence will be always executed.

Nowadays we write in many languages and we need to have a deep knowledge to do good stuff, but also we use many times the same structures, as they are more easy on remember, so we can have "silly" errors because some languages have a more strict structure than others.

And if you want to allow developers using other languages to write proper ObjectScript, as more similar is semantics to other languages, more easy will be to them to adopt to ObjectScript.

Hi, you can track any issue on https://tracker.cachequality.com

From here, you can report any issue, or ask for new features.

Hello David,  you can check licencing cost on https://www.cachequality.com/pricing. If you have any other question, don't hesitate to ask us!