Add new category to list pending actions

[mfroehlich (Marvin Fröhlich)]

Qube: Community 9.9

Hey, I would like to suggest a new category next to “Bug”, “Security hotspot” and “Code smell”. This would be something like “Pending action”.

This category could list things like

• Don’t forget to remove deprecated item foo
• Remove commented out code
• Rename variable Foo to foo
  etc.

Well, of course the use could change categorization at will. But some good defaults always help.

Things like deprected methods or classes to be removed and comented out code are neither bugs, not code smells and of course not security hotspots. Sometimes it is nice to have a report to list these things. But I don’t want to see them in any list of bugs or code smells, because it is plain wrong to name them like that. And any taken report of a project, that lists bugs or code smells, smells more than it has to. So I would possibly tend to disable these rules. But the results are still very usefull, but just not by adding them to the wrong list.

Of course there’s always the option to duplicate all projects, one to report all the bugs and code smells and one to list all the pending actions (that are named bugs or code smells here). But this would be very bloated.

What do you think?

[gab (Gabriel Vivas)]

Hi Marvin,

Thanks for bringing this up. I think that you are right: it feels odd to classify some of these as Bugs or Code Smells. Indeed, we have been thinking about this too. Once you start digging, you also find different examples, like code that is lacking in security while not being an immediate vulnerability.

We think we have come to the core of this. And we are actually changing the way we classify the results of our analysis.

You can read more about it here:

Introducing Clean Code in our products

Hello everyone, You might have noticed we relaunched our website and started to talk about Clean Code. We are now introducing a detailed definition of Clean Code in Sonar products. What is Clean Code? Clean Code is consistent, intentional, adaptable, and responsible. These attributes define what Clean Code is all about. Going forward, all Sonar products will adopt the Clean Code attributes as a way to more precisely categorize issues in your code. This complements our current approach, whe…

It’s not what you described, yet I’m curious to know if you think it would help.

Feel free to share any feedback!

Gab

[mfroehlich (Marvin Fröhlich)]

Thanks, Gabriel, I have commented the other thread. I’m sorry, that I cannot follow your enthusiasm over there. It’s a tough plan. Not sure, if these sweet words can actually be condensed into technical rules.

To be honest, something like my proposal will help a lot more for smaller projects.

You should take into account, that many code bases cannot be restarted from scratch. And applying some of the rules, that really affect the way the project is designed, is impossible. Nobody will pay for a partly redevelopment just to apply to some rules. Though still I want to know, if my code base fulfills some modern guidelines, while I don’t want to see in a Sonar report, that I don’t (yet) fulfill these guidelines, because it is not important for the project as a whole.

Having a list of “pending actions” and possibly more than a single quality profile, but multiple layers like “due”, “nice to have” and possibly more would help a lot for those projects. The Sonar report would separate some findings from bugs and code smells and name them “pending actions” and it would blend in “nice to have” only, if activated.

[gab (Gabriel Vivas)]

Thanks for your feedback Marvin. I think you bring up some interesting points about having different levels of information, and perhaps more deeply about having better support to adopt “cleaner” code more progressively, at one’s own pace, by prioritizing some aspects or some rules.

Our way of looking at this at Sonar, is that knowing is not enough, you need a method to tackle code issues sustainably. So we encourage a “Clean as you code” approach, where you have a super high standard for freshly introduced code or modified code, and mostly ignore old code to the degree that you can. I think this makes it hard to argue for introducing new small code smells, for example. I wonder what you think about this.

Yet again, I see your point about how projects are designed and not being able to change that overnight. We have been thinking about the “pending” concept for a while although more from the view of individual issues, sort of like a “Won’t fix”, except the issue doesn’t disappear forever.

Do you have a few examples of a rule that might not be compatible with the “Clean as you code” approach, in the sense that it would take a major project overhaul or big design change?

Gab

[mfroehlich (Marvin Fröhlich)]

Yes, “Clean as you code” is what I do all the time. And I promote this way of coding always. This includes (new) coding guidelines, new architechtures and techniques and of course format. I never format my code. I type it in the correct format.

Though still there are Sonar Reports and that like, that cover all the code. And if I want to hand out these reports to proof, that my code fulfills certain standards I cannot tell anyone, that most of the code base is old and hence does not need to follow these guidelines and doesn’t need to be secure and that like. As a result there is nothing like “new code” or “old code”, if you think about it this way.

Dealing with findings on issue level doesn’t work out for us at all. We want either the code to be leading or defined rules. It’s hard to find or track markers in Qube for certain lines of code. So, either the rules should be configured the “right way” to not produce FPs, which is to be preferred, or at worst we mark certain findings with NOSONAR, which is not good at all, but better then having a third place to look at. This is, why I would like to have all the rules to produce good results and not drop FPs here and there, which causes countless NOSONARs to appear in the code.

Yes, I have many examples of rules, that cause big overhauls. I cannot name them all. Many of them are just code smells by default. So people tend to say “ok, let’s just ignore them. It’s not a bug.” But I think, if you treat them this way, you can better deactivate the rule.

One example would be S3932, where not all branches of an if must be the same. Yes, it’s bad to have non complex code, that is duplicated like this. But it doesn’t hurt to duplicate trivial code at the benefit of simpler if statements.

Of course all the naming convention rules are clear candidates.

S110 wants me to restrict inheritence below a certain level. If I exceeded this level, it’s not a nobrainer to fix that. In the end this rule together with the cognitive complexity thing or number of arguments restriction are purely random anyway.

S106 cannot be easily retrofitted, if the code base is big enough.

Well, etc.