We often get the question how our TiCS Framework compares to SonarQube. Let's find out!
If you are not convinced by any of the statements made here, request a proof-of-concept via this link, and we’ll provide you with a free analysis of your project. This will allow you to compare SonarQube and TiCS yourself.
We often get the question of how our TiCS Framework compares to SonarQube. Oftentimes, companies that adopt TiCS have used SonarQube to some capacity in the past as well. We even see a lot of companies running both tools at the same time (SonarQube on a project level, and TiCS on an organizational level). This article will try to dive into the differences and demonstrate under which circumstances TiCS can be considered an alternative for SonarQube for your organization.
SonarQube is a code scanner that is used for Code Quality analysis. It helps engineers to determine the quality of their code based on a few different metrics. These can be divided into Bugs&Vulnerabilities, Code Smells, Coverage and Duplication. The tools and its dashboards are relatively technical are mostly meant for engineers. SonarQube has good performance compared to other tools, but this also means its analysis is shallower compared to other static analyzers like Coverity and CodeSonar. SonarQube is a great tool to start measuring tool on a team level. However, this is also a pitfall: we have seen many organizations where SonarQube was configured by each team individually, which makes central code quality governance difficult. Additionally, as teams can configure the tool on their own, many different rule sets are used within one organization. This makes comparing across different projects difficult, but it gives individual engineers and teams a lot more control when running the tool.
SonarQube's main dashboard
As the name suggests, the TiCS is a Framework that allows you to plug in best-in-class static analysis tools (e.g. Coverity, CodeSonar, C++Test) for each code quality metric you would like to measure, and maps all these tools against the same scoring model. This means that more metrics can be measured, and deeper analysis can be performed for security and reliability-related metrics. The downside of TiCS being a framework is that all tools that run under TiCS’ hood need to be configured and maintained. As a result, setting it up yourself is not a trivial task (however, our license includes a personal support engineer to do that for you!). TiCS measures many different code quality metrics, the 8 most important of which, are combined in the TIOBE Quality Indicator. The TIOBE Quality Indicator is an independent model against which all of our customers are scored, which allows for benchmarking. Another downside of the deeper analysis TiCS performs is that some of these metrics require longer analysis times compared to lighter-weight tools.
TiCS' main dashboard
One checkmark indicates a tool can do something, and two checkmarks indicate it is very good in this regard
Both tools have a lot in common, but where SonarQube shines as a fast lightweight tool for individual teams with budget constraints, TiCS is the tool for bringing code quality targets to an organizational level. As a developer, SonarQube offers more flexibility in terms of which rules you would like to enable, but if you are a team lead or engineering manager, you probably prefer that developers can not decide which rules to switch on an off. In short, if you value speed and deployability, SonarQube is the tool to use. If you value deeper analysis and a stanardized method of measuring software quality, we would advise you to take a look at our TiCS Framework.
Are you a SonarQube user and still in doubt whether you should make the switch? Request a free analysis for your project and compare the results!
Request a free analysis