Quality Gate condition for new code containing a unique code smell new to the code base

SonarQube Product Manager for a Day
1

This is mostly an idea that occurred to me, that I want to share. In the context of a Pull Request analysis specially, but maybe also for branch analysis. If you write new code that introduces a new unique code smell, then would it be possible to make the quality gate fail specifically for that reason?

It’s a common understanding that there are reasons why the code base has many pre-existing issues that you can’t solve immediately for some arbitrary reason. There’s also reasons why “new code” will have issues reported on it, that isn’t necessarily worth failing the quality gate. However, if new code introduces an issue of a type that is entirely new to the code base, then surely it could be possible to point that out specifically.

The example I’m thinking about is that after all the issues that violate some rule X have been resolved, it would be frustrating if other developers start to re-introduce violations of rule X.

Maybe avoiding this is already considered to be covered by other mechanics and practices, but I wanted to share the idea.

1 Like
3

Hi Torgeir

That’s a really interesting idea, thank you for sharing. I like the concept that the first instance of a rule that is new to a project could be treated differently.

I’ll share it with @vivek.reghunath our Clean As You Code Product Manager

Tom

4

Hello Torgeir,

Thanks for sharing the idea.
I feel that the first occurrence of a new rule violation can be a learning opportunity for the developer/team as well.
I will also invite the attention of @john.clifton , our Learn as You Code Product Manager.

There’s also reasons why “new code” will have issues reported on it, that aren’t necessarily worth failing the quality gate.

I am curious, in your case, which kinds of issues (in the new code) are not worth fixing?

5

It’s not necessarily that they’re not worth fixing in general, but more that they can be out of scope in a situation where you happen to touch those lines. The cognitive complexity rules is the example I’m thinking the most about. If you have to do a tiny fix in one of the functions affected by that, that could be a situation where it’s relevant to ignore a rule that is otherwise relevant.

1 Like
6

Thank you @vivek.reghunath. Spotting this sort of trend and highlighting it as a learning opportunity is certainly something we will explore.

1 Like