Nullable Reference Types: local option to promote warnings to errors.

[the-Arioch]

Can there be an option of "#pragma warning error nullable" to promote this class of warnings (and only this class) into full blown errors that fail the compilation? And do it locally on per-source-line basis (though by implication it would also go into csproj as well)

To facilitate a "clean start" now (and one day you would anyway do this in some new compiler version).

The option to "treat ALL warnings as errors" is overshot.
https://stackoverflow.com/questions/2520853/warning-as-error-how-to-rid-these

The option to track dozen of individual related warning IDs (CSnnnn) and to switch them one by one would both be very much boilerplate and fragile dependence upon implementation detail (thus a future bug, only a question how soon).

For example, this seems to be a complete as of somewhen list of NRT-related warnings: https://www.tabsoverspaces.com/233764-switch-to-errors-instead-of-warnings-for-nullable-reference-types-in-csharp-8
But the idea to be creating new future-proof code googling for this kind of blog posts is not appealing.

[CyrusNajmabadi]

The option to "treat ALL warnings as errors" is overshot.

I don't really buy that. It's not hard to go fix all warnings. Just turn that on and spend a little time cleaning up stuff that really should have been cleaned up in the past anyways.

The referenced SO post is particularly strange to me as the example they give:

I cannot figure out how to get rid of errors that basically should not be halting my compile in Visual Studio 2010 and should not be show stoppers, or at least I will fix them later, but I don't want the compile to just error and halt on these kinds of problems.

For example, I'm getting the following error:

    Error 1 Warning as Error: XML comment on 'ScrewTurn.Wiki.SearchEngine.Relevance.Finalize(float)' has a paramref tag for 'IsFinalized', but there is no parameter by that name C:\www\Wiki\Screwturn3_0_2_509\SearchEngine\Relevance.cs 60 70 SearchEngine

is one that really should be fixed. Why is that xml comment referencing something nonexistent. Might as well just fix it or delete that line.

[the-Arioch]

spend a little time cleaning up stuff

Yeah, we are always have a dozen of spare code monkeys ready to spend few days each to fixing all the warnings across all the codebase, just for the fun of it.

While we are running against the clock making new modules that should fit well into the inherited project as it is now.

This all-or-nothing puristic approach does not always work.

[YairHalberstadt]

@the-Arioch
It took me alone less than a week, on a million loc, which were heavily riddled with errors.

If you want to break it up into manageable chunks, then doing so in a project by project basis is a decent idea.

[yaakov-h]

Or, one compiler warning at a time. Or both.

In my experience, any codebase that doesn't build with warnings-as-errors contains one or more time bombs waiting to happen.

[CyrusNajmabadi]

Yeah, we are always have a dozen of spare code monkeys ready to spend few days each to fixing all the warnings across all the codebase,

Do a little at a time. Eventually you get into a clean state.

just for the fun of it.

Code hygiene pays dividends. Just consider the example that was linked to. It literally was incorrect documentation. That means someone could be confused by trying to figure out what the documentation was trying to say. The compiler was letting the developer know, and it would take likely just a few seconds to fix that up as part of work in that area.

Don't let broken windows become the norm for your code. Spend the time and effort to work on it.