CODEWITHSUNDEEP
javacommentssonarqubetodo
Metalhead
Metalhead

Reputation: 1449

How to handle TODO comments when sonar error is encountered

We have a large application and we have added the TODO rule to SonarQube quality gates that throws errors when TODO comments are found.

This encourages developers to remove TODO comments, which is scary, as the whole purpose of adding the TODO comment is lost.

Is there a way to keep the TODO comments by adding some sort of override or ignore comment similar to ESLint? We would like to defer dealing with the TODOs but still be notified of the TODO tasks left by developers when they do not fit the scope of a current ticket without blocking a build.

Upvotes: 8

Views: 15825

Answers (2)

ruffin
ruffin

Reputation: 17453

Looks like the answer is NOSONAR. In the question linked in the previous sentence, the OP had a variable whose name included the string TODO and they mentioned that variable in a comment (likely also bad for the reasons Ross points out -- if the variable name changes, does your comment change its spelling? etc), which still triggered the warning.

Changing the line to include NOSONAR allowed them to skip the quality gate.

/** Model which defines data from the oracle view V_THINGS_TODO blabla */

changes to

/** Model which defines data from the oracle view V_THINGS_TODO blabla NOSONAR */

But literally anything with NOSONAR in a comment on the line gets ignored.

//TODO: I prefer TODOs because they annoy future developers enough to remind us to fix them NOSONAR

This works well in .NET-land as well... Even works in html!:

<template data-sly-template.step>
   <!-- //NOSONAR --><li
       data-sly-use.localStep="MyAdapter"
       data-sly-test="${(wcmmode.edit && localStep.start) || !wcmmode.edit}"

Now I'm not necessarily arguing for NOSONAR use in general (though, ok ok, I did in a comment on Ross' answer), but whether or not you agree with Ross' excellent reasons for not using TODOs, this is how you stop SonarQube from yelling at you and blocking your build.

Upvotes: 0

Ross Drew
Ross Drew

Reputation: 8246

Remove the TODO, stop using them for anything that's not short term (for the length of a ticket or fork) and move them into tickets on your ticket tracking system.

TODO comments have multiple problems:-

  • they can be hard to find if you are using an IDE which doesn't auto locate them. (I know Devs who use sublime or even Emacs so a specific search would be needed)

  • whose job is it to find and fix these?

  • how is time spend on them tracked?

  • they can get out of date, like most comments. If someone fixes the problem without reading the TODO and leaves it there, it causes confusion. If another fix inadvertently fixes it, the comment is unknowingly left there.

  • You now have two issue tracking systems, one of internal documentation and one in whatever issue tracking system you use.

  • If you are writing TODOs then you are the very person with the knowledge to fix it. Someone coming along later will have to fix it based on a very short comment without description.

There's nothing more irritating than a piece of code by a developer who was too lazy to do a good job, so left it for the next guy

enter image description here

or one who wasn't lazy but was too scared to break something and just ended up making the problem more complex with minimal comments suggesting there's a problem

enter image description here

Upvotes: 5

Related Questions