Sonar Community Roundup, November 1 - November 7

Hi all,

November already?

Like every week, we’d like to take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback that drives continuous improvement in our products.

SonarQube Cloud:

  • @ftlvz couldn’t rename user groups, getting a Forbidden error every time. This was a regression from a recent change, and we got a fix out quickly. Thanks for the quick feedback!

Rules & Languages Improvements:

  • @Fred_D questioned the performance claims in typescript:S7728, which suggests using for...of instead of .forEach() for better performance. Benchmarks showed .forEach() actually performed faster in Chrome, Firefox, and Node. While the rule’s primary benefits are control flow and async/await support rather than raw speed, the performance-focused messaging in the rule description will be changed. PR already merged! Thanks!

  • vbnet:S5944 incorrectly flags functions with generic arguments and delegate invocations as using implicit return values, as @Footed discovered. Even though the function has a valid Return statement, the rule triggers on syntax like Of DllGetClassObject. A ticket was created for this false positive. Thanks for the detailed report!

  • javascript:S1444 triggers incorrectly in plain JavaScript files, as @what1s1ove found. The rule suggests making public static properties readonly, but this modifier is TypeScript-only and not available in .js files. JS-926 was created to fix this. Thanks!

  • javasecurity:S6096 incorrectly flags Zip Slip vulnerabilities when using Files.createTempFile() with zip entry names, as @AntoineL pointed out. According to the Java NIO documentation, this method validates file names and throws exceptions for invalid characters, making Zip Slip impossible. A fix has been merged!

  • python:S6663 flags false positives when using bracket notation with PySpark’s Row class, as @mbyrnepr2 reported. While row["name"] is valid for PySpark Row objects, the rule suggests using methods instead. A ticket was created to address this. Thanks!

  • @Belle discovered that java:S2189 doesn’t detect infinite loops involving AtomicBoolean. Code like while (!atomicBoolean.get()) { } should trigger a warning but doesn’t. JAVASE-147 was created to track this false negative. Thanks for the concise example!

Thank you again to everyone mentioned—and to those we may have missed—for your ongoing contributions in making this community stronger and helping us improve Sonar products.

If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!

1 Like