Both the Sun and Google Java style guides recommend setting off keywords with spaces in order to make them stand out, and not be mistaken for method calls, which should not have a space between the method name and the argument list (to be consistent with how functions are written in mathematical notation). Similarly, braces that are part of a control structure should have spaces. So, something like
if(foo (bar) > 5){
i–;
}else{
i++;
}
should be replaced with
if (foo(bar) > 5) {
i–;
} else {
i++;
}
(Of course, the braces part would contradict rule java:S1106, which says put them on separate lines, but that rule seems optional at this time.)
Parameterizing would be even better (some people may want it the opposite way).
Thank you for your suggestion. This rule is interesting and I totally agree that styling is important, however we can’t implement it for now. We currently focus our current efforts on vulnerabilities, bugs and maintainability issues, which leaves no time for styling rules.
As you said, this rule, just as any other styling rule, needs to be parametrised because there is no consensus on what style should be used. It can’t be activated by default because it would create a bad first user experience. If we enabled every styling rule, users would have to spend a lot of time configuring their Quality Profile before arriving at a state where SonarQube/SonarCloud/SonarLint are usable. Also in our experience rules which are not activated by default are often ignored. This is why we prefer to avoid styling rules for the time being.
We’ll come back to your suggestion once we have a better way to handle styling rules.
Don’t hesitate to suggest more rules. We can’t implement all of them but we always appreciate your contributions
Just for gits and shiggles, I created profiles in which I activated EVERYTHING. First, that brought the server to its knees – I had to double the heap size of the web component to 2G. Once that was cleared up, I noticed all the newly-activated style rules, that mostly contradicted one another. (Sometimes directly, like java:S1106 vs. java:S1105.) So it makes sense that you wouldn’t enable any of them out-of-the-box, as if you did, there would be no way to please them all, and if you just enabled one consistent set, it would basically mean picking one style.
I noticed that some of the style rules naturally go together
Maybe you could have a way to cluster various rules together. For instance, if you want One True Brace rules (and who would want anything else? ) you could have a profile for that (just activating a few rules), and a user’s production profile could inherit from that. (Then again, Java doesn’t allow multiple inheritance, so you’d have to call it an INTERFACE! )
From our experience, Quality Profiles are already a bit difficult to configure for many users. We currently group rules by tags (ex: spring, misra, etc…) so that they can be enabled together but this is not very intuitive. We will improve this at some point but it is a very big topic. If you want to see new features for rule selection don’t hesitate to create a new thread on https://community.sonarsource.com/c/suggestions/features/14 or contribute to an existing thread.
) you could have a profile for that (just activating a few rules), and a user’s production profile could inherit from that. (Then again, Java doesn’t allow multiple inheritance, so you’d have to call it an INTERFACE! 
)