Robert, the trigger is run after each commit.

Please, notice there is a misspelling and path must be ".github/workflows"


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 to have a more complete view, or contact me for a demo. I will be pleased to show you how it works!

It would be really useful if you can attach some examples about your "query" construction, so we can identify the different situations to be able to build proper rules.

So here we need a "Reserved word used as SQL property" rule, and this is a issue for readability and a best practice. Isn't it?

I think you propose a "Possible SQL injection" rule, to detect when sql is created from strings concatenation without proper parametrization.

Hi Evgeny!

I think it's a nice idea to have a default profile based on Community voted rules, which will allow proper usage of Studio/Atelier/VSCode plugins without a SonarQube server.

Also, we encourage anyone to propose new helpful rules or (as we are doing here) to discuss about existing ones to get a revised version of them based on Community consensus.