· Apr 4, 2016

Static code analysis tool for ObjectScript (presented at Phoenix)

Hello community!

At the global summit in Phoenix, we (Lite Solutions) will be presenting a tool performing static code analysis on ObjectScript source files. You can see it in action at this URL:


Technically, the tool is a language plugin over SonarQube (http://sonarqube.org) and consists of three main parts:

  • parsing the language,
  • collecting metrics,
  • collecting issues.

The third point is where we kindly request for feedback.

Explanation: issues are the result of rules being triggered by inspecting the source files. But while we do have some experience with the language, this experience is too "fresh" for us to accurately estimate the severity/time to fix of such issues. The list of rules, along with their severity and time to fix can be found here:


We are eager for feedback:

  • any replies to this thread will be answered promptly;
  • if you are at Phoenix, you can wait until then... Or not :)

As to the feedback we seek:

  • do you think a time to fix is overestimated/underestimated?
  • do you think the severity is overestimated/underestimated?
  • can the issue descriptions be improved?
  • are there other rules you would like to see?

Looking forward to your answers!


Discussion (6)4
Log in or sign up to continue

Very nice tools, but I disagreed with majority of fatal problems (especially in my projects :)). And who said that I could not write $$$MACRO as a single statement? Where did you get one?

So... it would require a lot of fine tuning to work properly accroding to the experienced Cache' ObjectScript programmer tastes. Java idioms ported as-is to ObjectScript just doesn't work.


This is precisely why I'm asking for feedback about default severities :) Do I take it that you think the severity is too high? If yes, what do you think it should be?

Note that if you wish to, I can set up an account so that you can modify which rules are active and which are not, along with the default severities (just send me a mail). But you talk about fine tuning, I'd rather the settings were good enough that the amount of fine tuning spent is minimized :)

I am a seasoned Java developer myself and I also disagree with many of the rules of SonarQube's Java plugin. But admittedly, I revere type safety and it somewhat shows in the rules :)


As to macros, well, you can write a macro as a statement, sure, but the problem I see is that it is an opaque statement. What does this macro do? Does it exit the method? If a variable is passed as an argument, does it modify this variable? Does it increase the complexity? If yes, by how much? Basically, this is the reason for the rule. Nothing Java related :)

In the future the plugin may expand macros, in fact; right now however this is not supported...


I don't understand what you mean?

As you may have seen on the main page, there is an email to which you can write so that your code can get analyzed on this very site. Note that this is a compromise: you get the analysis for free, but the code is visible to everyone; which is why open source projects written in COS get the most benefit from it.

Related to that somehow is that from our experience, most such projects still use Studio's export facility which exports to XML; fortunately, we have a solution to turn those exports into plain source files (https://github.com/litesolutions/cache-import). Once Atelier gains wider adoption, things may change, in a good way: no need to massage XML anymore!