28
Is it a bad practice to replace compiler warnings with a bunch of TODO notes? (lemmy.zip)
submitted 5 months ago by to c/programming@programming.dev
11 comments fedilink hide all child comments
 

I am using rust, but this applies to many other languages, I get warnings like, dead code, unused variables, and etc, and while I remove most of them, there are some im not sure of, I like running my program and there being 0 warnings, or 0 warnings as i scroll down my code, so for things im unsure of, i mark them so the compiler doesn't put warnings there. I also add comments, starting with TODO:, it has some information about what to think about when i revisit it, also the todo's gets highlighed in my IDE with my extension, but is this bad practice?

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 5 months ago*

Think about whether TODOs will be revisited, and how you can guarantee that. What do you gain and lose by replacing warnings with TODOs.

In my projects and work projects, I advocate for:

  • Warnings and TODOs are fine only in initial development before release/stability and in feature branches during development
  • TODOs are almost never revisited, so document state and information instead of hypotheticals; document opportunities over TODOs, document known shortcomings and risks, etc
  • If there is good reason to keep and ignore warnings, document the reasoning, and we can update our CI/Jenkins quality gate to a new baseline of accepted warnings instead of suppressing them (this pretty much never happens)

Dotnet warning suppression attributes have a Justification property. Editorconfig severity, disabling, suppression can have a comment.

If it's your own project and you know when and how you will revisit, what do you gain by dropping the warning? A no-warning, but then you have TODOs with the same uncertainties?

  • permalink
  • fedilink
  • source
    •