Description: Improving the TODO rules for C#.
Why is there an issue: Presently, TODOs are getting flagged even if they have a tracking number, which might be intentional. I think the original point was to ensure devs aren’t forgetting the TODOs for the PRs; but a legitimate use case might be TODO: 654321 as a follow-up
Example non compliant code:
TODO: 687 - Update the gating NuGet and match with here (a sample title)
This would be flagged due to the TODO.
Type: Code Smell.
Hey @Arman_Hilmioglu, welcome to our community and great to see you 
.
I would say that it’s a code smell to have in general TODOs in the code. There’s no way to verify, for example, that the ticket is still open, or that it exists in the first place.
And I’d say that it could be an advantage to see how many TODOs are around in the code (tracked or not tracked). Or not. It’s subjective and depends on the team processes.
Indeed, a TODO without an assigned (open) ticket should be caught during review.
We’ve had an internal discussion and our general idea is that the TODO is a code smell.
However, inside Visual Studio you can configure the keywords to show up in TaskList (Tools → Options → environment → task list → tokens).
If you need, you can define something else like "Ticket: " in VS configuration.
I think that in many use cases it is OK to assume that TODO followed by a certain link pattern (e.g. https://<company-name>.atlassian.net/jira/browse/<project-prefix>-*) is an indication of awareness for the TODO item.
In my company we have a custom to add TODO comments with links to Jira tickets for followup and this ‘dance’ of going to SonarCloud and marking the TODO as ‘accepted’ is just tedious without any added value.
Regardless of your point of view, I think that I’m talking on behalf of many others when I say that we would very appreciate if you respect your costumers discretion and give them the choice to configure this behavior. you can still make it an opt-in feature if you think this is bad practice, but in many cases your assumptions of the users’ interaction with your system is different than you think.
Thanks!
I would argue that it still something that is not solved, and therefore still an issue.
However, If you would like your custom rule, you could - for this case - also design a new one. You could even - although discouraged by Microsoft in general, but here you might have a use case - let your custom rule check if the link exists, and if not, flag it as a warning or even error.
For a general purpose rule set like Sonar’s however, I think the current implementation is just fine.