Code quality tools measure the code quality against defined rulesets. SInce a couple of months a website exists, which is monitoring all TYPO3 extensions available in the TER. What is checked and how can you benefit from this service?
The service is based on sonarqube.org, an open source project. It’s goal is to support enhance code quality continuously. It is possible to integrate it in continuous integration environments like JenkinsCI or Travis. But it is also possible to provide the analysis via a stand-alone website, where the various projects are imported and analyzed.
This is the approach, that Marketing Factory Consulting has choosen, to monitor all TYPO3 extensions, which are available via the TYPO3 Extension Repository. As of the time of writing over 7300 extensions are checked. A check is done, whenever an extension is uploaded to the TER. The service is available at https://ter-sonarqube.marketing-factory.de/projects
There are some concepts behind sonarcube: Rules, quality profiles, levels of violations and quality gates.
A rule is the smallest entity of the concepts. It defines a violation, which is detected in the code. Sonarqube delivers over 120 rules for php. An overview of all rules is available here .
A quality profile consists of a set of rules, which can be defined by the sonarcube admin. Several profiles are available by default for Drupal and PSR-2. The setting for TYPO3 is based on the “Sonar way”. At the time of writing it is a set of 62 rules.
Levels of violations
To each rule a violation level is assigned. There are three of them: Bugs, vulnerabilities and code smells.
Bugs are “issues that represents something wrong in the code. If this has not broken yet, it will, and probably at the worst possible moment. This needs to be fixed. Yesterday.”
A vulnerability is a security-related issue which represents a potential backdoor for attackers. More information about these rules is available at https://docs.sonarqube.org/display/SONAR/Security-related+rules.
The scope of code smells is about the maintainability of the code. The better the rating in this area the easier it is for its maintainers to work on the code.
In the official documentation this is defined as a set of conditions, which must be met by the project to be released to production. If this set is not matched, the project cannot be released. In case of TYPO3 extensions, this is “just” a marker, whether a new release complies will pass the quality gate.
Each level of violation has its own limitations, that must be met by the project:
- new bugs: no new bugs allowed
- new vulnerabilities: no new vulnerabilities allowed
- code smell ratio (aka “Technical Debt Ratio on New Code”): max 5% in new code
But now enough of the theory, let’s have a look at the website.
Project list and filters
The main entry point is the project overview at https://ter-sonarqube.marketing-factory.de/projects. Without any filters you get a list of all extensions covered by the website. They are sorted by the upload date to the TER starting with the youngest.
An example is the extension “groupdelegation”:
On each extension entry there are six ratings available. Each rating can have a status from A (best) to E (worst).
Quality gate shows whether the extension passed the quality gate as described above.
The Reliability Rating reflects the severity of bugs.
The Security Rating sums up the vulnerabilities found in the code.
The Maintanablilty Rating shows a ratio between the cost of development and the cost of fixing all issues found. If the time needed is less than 5% of the original development time, it gets the rating “A”, if it is more than 21%, then the extension is rated “D”.
The Coverage percentage is always zero. The sonarqube docs are writing about the coverage by unit tests. But I can’t believe, that there are no unit tests in extensions.
Duplications show the blocks of code which are similar throughout the project. For php projects the limit is ten lines of code. Differences in indentations and string literals are ignored.
The Size of the code reflects the number of lines of code in this project.
On the left side are several filters to reduce the number of shown extensions or you may want to search for your own extension(s).
After clicking on a project title, the “homepage” of the extension is shown.
This is a more detailed overview about the issues of the extension. The “code smell” section lists the number of smells and the estimated time to remove them.
The issues view lists all issues which should be solved and tells in detail where the problem is. If you have a project with many issues, you can use the filter on the left sidebar, to narrow down on what you would like to work on.
This is a really cool tool provided by Marketing Factory Consulting to check extensions against a common ruleset. This is valid especially for you as an extension author.
Please keep in mind that this is not a rating of the functionality of an extension or whether it is bug free or not. An extension can have a rating “D” in every field, but can fit to your needs in every way!
For this initiative, I have got three wishes:
1) Let it run under an official typo3.org domain.
This can be really helpful for extension authors and will help to enhance their code quality.
2) Create official rules
It would be helpful, if the defined quality profile is endorsed by the TYPO3 core team to have commonly acknowledged rules for every extension.
3) Include TYPO3 core
When there are the rules for extensions, why shouldn’t they be valid for the TYPO3 core. So I would like to see the TYPO3 core in this initiative too (having in mind that there is much “legacy” code in it).
I want to thank my supporters via patreon.com, who make the blog posts possible:
If you appreciate my blog and want to support me, you can say “Thank You!”. Find out the possiblities here: