During demo sessions of Promyze, we show how the tool helps you share best coding practices, and review them with your team. This demo also includes a feature that automatically prompts suggestions to developers, both in their IDE & during the code review, whenever some of their best practices aren’t followed.
For the demo audience, this behavior looks similar to those implemented in another category of tools, the linters, such as SonarQube, Codacy, Eslint, and more. Then comes often the question: “How Promyze is different from SonarQube (or any other linter) ?” – Answer is simple, so let’s write it down.
In a nutshell, they ensure that your source code complies with a set of coding rules and doesn’t contain security vulnerabilities. You can define your minimum quality levels to reach for delivering software, and include them in your CI/CD process. You can also get dashboards with an overview of the quality issues over a project, to prioritize your remediation efforts.
Their main strength is their ability to detect issues in the code, based on pre-defined coding rules. Depending on the editor, they’re either public or proprietary; in the case of SonarQube, all the rules are publicly available online. This is an important point: they only detect what they can detect. As Dijkstra said about software testing that “only shows the presence of bugs, nor their absences”, linters can only show some issues in the code, but can’t prove you don’t have other issues. It acts as a security net. If they could detect everything, why would you still keep your code review process with human support? 😉
Finally, linters target universal practices (even though you can often write custom rules) that can be automatically detected through source code analysis, and ensure your code will be compliant with them; But they won’t help you to come up with them.
With Promyze, the focus is to leverage knowledge sharing among developers and foster interactions to align coding standards in the context of an organization. It raises developers’ skills and gives them the opportunity to suggest a new coding standard that will be reviewed during a collective workshop, leading to continuously improving their practices.
Promyze gathers emerging practices specific to each team and the organization, tailored to their context, and ensures they’ll be pushed and understood by developers (even if they can’t be caught through to static analysis).
Also, the main use cases differ from linters and include:
And indeed, when possible, users can define regular expressions to prompt developers when best practices aren’t applied. That’s all for the linters-like features. But most of the custom practices in Promyze can’t be detected through automatic code analysis. And that’s why knowledge-sharing processes, including best practices sharing, code review, pair/mob programming have a crucial role.
It makes sense to use both tools as they’re complementary and aren’t designed for the same goal:
As a final word, we had the chance to discuss with Freddy Mallet, one of the SonarSource co-founders and today CPO at Reviewpad, who shared with us his thoughts on that topic:
No one would challenge today the usefulness of code linters. All those linters are some kind of basic spelling and grammar checkers for source code. But writing a good document is also about using a suitable tone and the appropriate expressions according to a given context. This is what is unlocked at scale by Promyze across the entire organization.
Hope this post will help to understand how both tools can leverage your best coding practices🙂 Possible integrations between Promyze and linters are not excluded so far: check what’s next to follow what we’re working on!
To start sharing your tailored best coding practices, get started now for free.
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition.
Crafted from Bordeaux, France.