SQ 8.6.0.39681
There is a tag called “style” which is applied to rules java:S1120 (indentation) and java:S122 (separate lines). Clearly, there are lots of other rules that are related to style. There are 5 rules just related to braces (java:S1105-1109) that aren’t tagged “style” but they are tagged “convention”; OK, what’s the difference between style and convention?
Hi @MisterPi,
Thanks for raising this problem. It is confusing indeed. The style tag has been used by mistake in a few rules. It should have been convention. I’ll fix it.
The convention tag is described in SonarQube and SonarCloud documentation. It includes styling issues.
So you’re saying “style” wasn’t supposed to be used, and all style-related rules should go under “convention”? (I looked up all rules with the style tag, and there are only 15, which are the same two rules repeated for various relevant languages.)
Actually, a style tag might be useful – if done consistently. There are currently 46 rules with the convention tag (48 if you move the two style-tagged rules there). It seems like the ones related purely to syntax, like the curly-brace ones, indentation, etc., would be better in a separate category, especially as those are often used in many languages, whereas things like “X should implement Y” are semantic and very language-specific.
Just to make a suggestion: I think Sonar should think about having some internal documentation about API’s to ensure that developers do things consistently. For instance, there are a lot of cases in web_api where two functions will use different names for the exact same parameter. It appears that different developers went off in separate corners, each implementing their own function independently.
Yes, at least as a first step to make things consistent. The current definition of the “convention” label includes styling. It doesn’t mean that we can’t improve things on the long run when it makes sense.
I agree that “convention” as a tag is a bit generic. Semantic rules such as [RSPEC-2157|[RSPEC-2157] - Jira] have additional tags to make the distinction, ex: api-design. The solution might be to add both convention and style tags to purely styling rules. I’ll think about it.
Could you create a separate thread for this topic? Otherwise this one will become confusing.
Thanks.
Well, it relates to this topic (because obviously someone decided to create a tag “style” without checking a central list). But I’m not sure what category to put it under – it’s not a bug, feature, or question; it’s a suggestion for the developers at Sonar. But Category seems to be a mandatory field.
Hi @MisterPi,
I think you can put in in the “Bug” category as this is a problem to fix. We will need the name of the confusing APIs.
OK, I put it under You should have internal docs to promote consistency among implementations. Sorry if it sounds kind of bashy, but you did ask for examples… 