Hi,
I am wondering if there is a tool (maybe plugin for sonarqube etc) that performs continuous inspection of code quality, which allows automatic static analysis of DAML code in order to detect code smells, bugs etc.
Thanks for any help!
6 Likes
Hi @novusopt, and welcome to the forum!
The VSCode plugin includes a linter, which should provide you with suggestions for writing cleaner code. These should show up as blue squiggly lines in your IDE. It should work out-of-the box, if you’ve installed the VSCode DAML plugin. Here’s an example output:
daml/Main.daml|161 col 4| linter:Information:/home/luciano/src/monads/daml/Main.daml:161:4-17: Suggestion: Use <$> Found: pure (.) <*> u Perhaps: ((.) <$> u)
So this is saying I should replace pure (.) <*> u with ((.) <$> u).
Unfortunately we don’t have automatic syntax formatting … that’s something I’d really appreciate!
5 Likes
A request for a code-formatter comes up from time to time. It’s not as straight forward to integrate as we might hope for some low-level technical details but not impossible. Getting this in requires lots of upvotes!
6 Likes
Upvote!
4 Likes
Hi all,
thanks for your reply!
I know there is linter and that works quite good.
I am more addressing the static analysis of DAML code which allows a more automated code review in order to check for potential problems in the code base.
Thanks a lot!
1 Like
Hi @novusopt,
what sort of potential problems do you have in mind that the static analysis tool should catch that are not covered by our linter? Some examples would be really helpful to understand what you’re aiming at.
Many thanks,
Martin.
Welcome @novusopt; it’s an interesting question you’ve asked.
In the DAML development ecosystem, it would be accurate to say that these jobs are handled by the compiler’s type-checker and linter.
All type checkers perform automatic static analysis. For example, when you are thinking about using SonarQube with Java, the choice is not “we use no automatic static analysis” versus “we use automatic static analysis”; a better way to describe it is “we find javac’s static analysis sufficient” versus “we want such and such additional checks to be applied on top of those supplied by javac”.
In other words, simply attaching SonarQube to your CI does not mean you’ve gone from 0 to 60, so to speak, but that you’ve stepped on the gas a little, or a lot. Additionally, there is no way to prove you’ve reached “maximum speed” in this respect, even if you turn on every check you can see.
There are a few further nuances.
How good are the core syntactic and typing rules of the language?
To consider an extreme example: suppose that you decided to use “Kafe”, an imaginary language like Java, but whose compiler incorporated every extra check you desired from SonarQube. For you, in this case, SonarQube would have no value for your “Kafe” development process. Your SonarQube-less Kafe process would be doing no less “automated code review in order to check…” than the alternative Java-plus-SonarQube process, by definition.
The better the core of a language enforces safety, the less room there is for general-purpose extra tools to add value.
How well is the design space of “additional checks” explored?
A check that makes sense for one language may not make sense for another. For example, null-related checks may be hugely valuable for SonarQube on Java, but don’t even make sense for DAML, which does not allow untyped null or uninitialized variables at all.
That’s why @Martin_Huschenbett’s question above is definitely the first thing you should consider; the details matter here.
To what degree can you influence the rules of the language itself?
Suppose a SonarQube developer considered a particular Java rule so valuable that it ought to be followed at all times. It would make the most sense, then, to incorporate that rule into the Java language. What are this developer’s practical options for doing so? They are limited, to understate matters; the most practical approach is to add this rule to an external tool.
By contrast, if the DAML developers here think a particular check is so valuable for DAML, they can add this rule directly into the DAML core, implementing it in the compiler; for checks that are more “code smell”-like, and thus should be optional checks rather than required, they can define them in the linter, which also does its job by means of static analysis. There’s no need to defer to CI checks that can simply be done immediately, errors reported to the developer as quickly as possible within VS Code.
3 Likes
Hi Stephen, hi Martin
thx a lot for your comprehensive answer!
@Martin_Huschenbett: static code analysis provides also heuristics and metrics.
As an example: maintainability Index, cyclomatic complexity, lines of code etc…
thx a lot!