Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In big codebases, warnings are useless. No one reads them.

They usually contain thousands of items from different plugins, designers, etc. Sorting through them all is impractical.

Errors are not just about protecting a developer from himself, but more importantly, protecting developers in a team from one another.

If the compiler can't produce an error, the whole feature is pointless.



I worked on some fairly large C# projects where the teams had zero-warning policies. It's not that difficult to achieve with a bit of discipline. Warnings in third-party dependencies only show up if you build them from source, but these days it's a lot easier to get your third-party dependencies from NuGet instead.

That being said, I don't think warnings would be a good way to go on this case, because the sheer number of warnings generated by these new rules in existing, large (and mostly bug-free) projects would make it very difficult to reestablish a zero-warnings state. Developers on the team will just get undisciplined due the the broken windows effect.


Yup. We have a zero-warning policy, and there's a setting in every project you can enable to treat warnings as errors, which we use.


Warn-as-error can be set for individual warnings as well as for every warning.

However if your build is spitting thousands of warnings and no one cares, that sounds like an issue someone should be looking at...




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: