Programming

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"