At least for the Roslyn based rules the URL’s explaining the rule are routed to: https://rules.sonarsource.com/*.
This endpoint seems gone. If this is intentional, please consider
Hi,
Can you provide your context for this? Is this in SonarQube for IDE or somewhere else?
For your questions, please see this update:
Ann
Sure: The Sonar analyzers are built on Roslyn (I assume you know that). Every rule contains a summary. One of those properties is a URL to navigate to for further details.
IDE’s such as Visual Studio (Code) and Ryder will allow developers to navigate to those endpoints once a certain issue occurs. So, for Rule S6964 the URL provided (that used to work until recently) is https://rules.sonarsource.com/csharp/RSPEC-6964.
Hi,
Thanks for clarifying. I’ve flagged this for the language experts since it looks like they need to take some sort of action.
Ann
Hi,
Thank you for reporting this. We’ve fixed this yesterday by removing the link. It will be part of the next analyzer release.
So if I understand correctly, you decided to make the documentation only available by using the Sonar plugin from now on?
The website rules.sonarsource.com that we linked was decommissioned, so we don’t have a suitable URL to use anymore from standalone NuGet packages. So as a consequence, yes.
SonarQube for IDE extensions, as well as SonarQube Server/Cloud have built-in ways of showing the relevant rule descriptions.
isn’t this kind of “closing the door” of something former openly available? If i want to - say - tell a colleague about the rules that make sonarqube such a great product.
I guess there has to be an alternative (and obviously preferred by you) way of me using a web browser, to navigate to a rules-listing, that is current and relevant and easily navigatable? The only thing that comes to my mind right now would be next.sonarqube.com/sonarqube/coding_rules … is this also your POV?
Oh and just on top of that: decommissioning rules.sonarsource.com after over five years existance (at least “waybackmachine snapshot age”) without a 301 to something comparatively “as useful as” resource (e.g. maybe the one i mentioned above) is not one of the top moves i’d think about. When thinking about it. While i’d not like to be in need of thinking about, at all.
To me, this below is just (maybe unplanned) bad UX
Hi @daniel,
Please see this thread:
Please also keep in mind that not every SonarSourcer has a hand in every SonarSource decision.
Thx,
Ann
