[deleted]

tailspin2019 2 days ago | parent [-]

The article does mention they only turn on “TreatWarningAsErrors” in production builds.

It’s definitely a tough balance to strike. I go back and forth on this myself.

Maybe the happy medium is to have everything strictly enforced in CI, relatively relaxed settings during normal dev loop builds and then perhaps a pre-commit build configuration that forces/reminds you to do one production build before pushing… (which if you miss, just means you may end up with a failed CI build to fix…)

▲

Kuraj 2 days ago | parent [-]

The original comment was about whether these things should be treated as errors during the local development process, or during CI for greenfield projects.

I deleted it after realizing that the article actually does address this. But I'm still relieved that I'm not the only one with the dillema.

> which if you miss, just means you may end up with a failed CI build to fix…

Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows (maybe after making that mistake once or twice :-)) that they can't just be ignored because they will fail down the road.

	▲	tailspin2019 2 days ago \| parent [-]
		> Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows that they can't just be ignored because they will fail down the road. Yeah I agree. This has got me thinking a bit more actually about how to optimise build configurations much more deliberately. Dev loop builds vs “normal” (local) builds vs production builds. I got into the habit of turning on TreatWarningsAsErrors in greenfield .NET projects, trying to be a disciplined developer… But often these warnings can be a distraction during fast iterations… I think I may change my policy…