Programming

Fix the warnings first. By all experience, later is never.

First specs, then a (perhaps semi-formal) API description, then implementation, then first tests, then fix warnings, then rigorous tests, then fix all bugs before adding more features. It sounds contra-intuitive, but you go faster this way.

It is bad practice. You'll obviously have 0 warnings if you hide the warnings. You don't go from warnings to YOLO mode. You should compile with "warnings as errors" and fix those if you want to really remove those warnings.

It's not ideal.

Depending on the kind of warning, you may be able to re-write the code in question including a 'todo!()' to capture the "i need to think about this" case.

This way you get a crash at runtime. This is preferable to continuing execution with incorrect computation.

It's best just to fix the warnings ASAP. They are usually trivial anyway.

I treat warning as todos. Fix them all before I release something. I would only ever disable one if I know for a fact the warning is a false positive.

I would question why you are seeing so many warnings you are not sure about? If you keep on top of them you really shouldn't have that many. Marking them all as allowed with a Todo comment feels just like you are burying you head in the sand.

I would leave them all there to keep nudging you to investigate and remove them. Hiding them behind a Todo will just mean you will ignore them. And warnings are important, they very likely point to a problem, even if that is just the code could be simpler. It is rare they are true false positives.

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?

Depends. I would flag it in a code review on our product, and same for most TODO comments. It's bad practice to leave them for your team to deal with, or even for yourself two years later.

But for explorative coding (mostly just one person, things like game development or creative coding, or before finishing your branch) I think dead code warnings do more damage than they help. They make you look at things not worth looking at right now, until you figured out what you want to build. Like unused structs or imports just because you commented out some line to test something. I didn't turn all annoyances off, but I feel I should. I have a hard time just ignoring them. I think it's better to enable them later when the code is stabilizing, to clean up experiments that didn't work out. When I just ignore them I also ignore a more important warnings, and waste time wondering why my stuff isn't working while the compiler is actually telling me why.

Also, in Rust many clippy defaults are too pedantic IMO, so I turn them off for good. Here is what I currently use:

[lints.rust]  
dead_code = "allow"  

[lints.clippy]  
new_without_default = "allow"  
match_like_matches_macro = "allow"  
manual_range_patterns = "allow"  
comparison_chain = "allow"  
collapsible_if = "allow"  
collapsible_else_if = "allow"  
let_and_return = "allow"  
identity_op = "allow"  # I'll multiply by one whenever I like!  
# Just disable all style hints?  
# style = "allow"  

Could also do this:

#[expect(lint, reason = "TODO: #issue")]

Edit: to clarify, #issue is an issue number that points to a related issue or task. Could also just explain it inline, but if you have a task tracker, better to make a task instead.

I like to treat warnings as errors and refuse releases with errors.

Occasionally I disable single warning in a specific file because it does not make sense.

Using TODO also makes sense, I'm mostly used to seeing them years after when debugging.

In your case it sounds like you may end up ignoring all the TODO's as too many of them become noise. I would instead disable the specific warnings in the compilers options, instead of in the code, and then deal with the remaining.

Later you can disable one warning at a time and fix it.

Can you not output it into a text file like maybe?

make &> todo.log

I would say it maybe makes sense to do that for team based projects so your TODOs don't impact other people finding new warnings in their code.

For solo projects I don't think that makes any sense.