We have been collecting the Coding Standards and Best Practices to build a static code analyzer (as @Evgeny Shvarov mentioned). In following link you will find all the rules we have developed, including wrong and rigth coding examples and how to solve them:


The code review can be done with our ObjectScriptQuality tool, which can be integrated with your preferred development tool, so developers have the code review at time.

You can test the tool uploading an ObjectScript project to github, or you can install the server to test it for 2 weeks. Also, you can install the development environment plugin and analyze code in standalone mode, which is free of charge.

Hi Alexey,

Of course following known-patterns it works properly. But, in my opinion, you are delegating too many responsabilities to the developer, while with TRY/CATCH/THROW you just delegate what to do when an error happens. You can forget about how is internally working or wondering if a call to a library is generating a collateral error. As Caché is OOP (aside backwards compatibility), we should also use the more modern error handling supported by the language.

Nowadays systems are getting more and more complex and we need to abstract and reduce logic when possible, and get things as simple an readable as possible.

Hi Joaquin,

As Evgeny told, we solve lint check using CacheQuality, which is a objectscript plugin for SonarQube. We also integrate it on Caché Studio, Atelier and VSCode, so you can have a first check on your development tool.

We also integrate the Test Coverage Tool, so you will have the full project view from one point!

Please, check https://www.cachequality.com/ to have a more complete view, or contact me for a demo. I will be pleased to show you how it works!

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 Evgeny,

When we refer to Code Coverage we mean "how many source code has been tested". We measure Code Coverage on the Unit Test execution.

As ObjectScript does not have an official Unit Test Framework, we will provide such Framework. Or if a customer has a custom Unit Test Framework, we will help to include some modifications to allow Code Coverage to be measured.