Sonar Community Roundup, August 24 - August 30

Clean Code Sonar Updates
1

Hi all,

It’s been quite a week in the Community. @Colin announced last week that he’d be vacationing this week, and I arrived Monday morning to find us in the throes of a full-blown spam attack. The timing was pure coincidence, I’m sure. :sweat_smile:

My thanks go out to everyone who helped with flagging the spam. And to mitigate the problem going forward, we’ve temporarily enabled manual approval for new user accounts. A better long-term solution is in the works. Apologies to those who experienced delays and friction signing up this week. Hopefully, we’ll be back to normal soon. :pray:

For those who did get in and offered us feedback, well, we’re grateful every time you help us improve. So like every week we want to spend some time acknowledging everyone who prompted interesting discussions and gave us feedback to help us continuously improve.

SonarQube:

  • With SonarScanner 6.0 and the SonarScanner for .NET 7.0, we changed the default value for sonar.host.url from localhost:9000 to SonarCloud. And unfortunately, if you’re relying on the old value, the error isn’t helpful. Plus, we kinda flubbed it on the docs side too. Thanks for pointing it out @guwirth. I’ve already seen an improved error message from one of the scanners. We’ll fix the others, the documentation, and the underlying release process that led to the confusion.

  • @Wiebke noticed that Quality Profile backup files don’t include rule prioritization. Well spotted! We’ll fix it with SONAR-22912.

  • For most analysis properties, we trim the values, but not for sonar.host.url in SonarScanner for NPM, as @klemen found. SCANNPM-44 will fix it.

  • @molecule got an NPE during analysis as the result of an interesting combination of old-school (project creation during initial analysis, where Anyone has execute analysis) and new-wave (GitHub integration) that makes automatic provisioning fall down and go boom. While Anyone is still around to be granted access, we don’t consider its use a good practice. But NPEs are always bad, and we’ll fix it with SONAR-22860.

SonarCloud:

  • We’ve known for a long time that what I call the Quality Gate fudge factor is a problem for some users. What it does is turn off conditions on coverage and duplications when fewer than 20 lines are changed. We eventually added a switch to turn it off in SonarQube, but since we still haven’t gotten around to that in SonarCloud, it was @zbigniew-malcherczyk’s report that finally prompted us to at least put it in the docs. There’s an internal ticket for that that should be handled soon.

  • @MOHIT_DANGWAL let us know that the SonarCloud UI stopped working in Edge. Thanks for the report! We’ll get it fixed.

  • Our documentation includes how to import coverage on an Azure DevOps windows-latest agent, but not ubuntu-latest, as @tbejarno noted. Good point. We’ll fix it.

SonarLint:

  • SonarLint for IntelliJ doesn’t handle bare Git repositories well (at all?). Thanks @tschindler, @marcelomartins and @eroller for helping us nail down this problem and where it happens! We’ll tackle it with SLCORE-926 and SLCORE-927.

  • We’re currently ignoring files in Rider that aren’t part of the solution directory. SLI-1556 will fix that. Thanks @velden for your report and help in nailing down the problem!

Rule & Language improvements:

  • @alecmev and @mmospanenko pointed out that javascript:S128 uses CodePath#currentSegments, which was removed in ESLint 9. That makes the rule crash in switches. Thanks for letting us know. We’ll fix it with JS-296.

  • On a closely related note, @Brendan_Mulholland learned the hard way that version 2.0.1 of eslint-plugin-sonarjs isn’t compatible with ESLint 9. Until we get there, we’re going to update the README, so other users aren’t surprised too.

  • csharpsquid:S6667 raises an issue when you log some details about an exception and then rethrow it. @Valentijn doesn’t think it should. As it happens, we don’t either. :joy: Thanks! We’ll fix it with NET-87

  • @vodoc82730 suggested that java:S1643 shouldn’t raise an issue for string concatenation in a loop. Despite @Bachri_Abdel’s spirited defense of the performance of using a StringBuilder instead, we’ve nonetheless created SONARJAVA-5105 to modify the rule. The discussion is ongoing, though, so let’s see what changes (if any) are actually made. :popcorn:

Once more, we extend our thanks to everyone mentioned here - and those we may have missed - for their efforts in strengthening this community and enhancing our Sonar products.

Please leave your own recognitions below – whether for another community member or a SonarSourcer who assisted you this week. If there’s someone you think should be acknowledged in next week’s roundup, don’t hesitate to let us know.

 
@ganncamp, @Colin, and @leith.darawsheh

3 Likes