3 ms·

Curious. How do you know if you've added the 8001st warning that indicates that you did something ill-advised? It seems that such a huge warning count makes it

Curious. How do you know if you've added the 8001st warning that indicates that you did something ill-advised? It seems that such a huge warning count makes it very hard for the compiler to tell you things. I've generally found it quite practical to get warning counts to zero with some combination of fixing the issues and disabling warnings that have a poor signal-to-noise ratio. The one exception was /analyze builds. There I added filtering so that I could treat some warning types as fatal, and others would be reported on only when they were new.

ThePadawan 6y ago
> Curious. How do you know if you've added the 8001st warning that indicates that you did something ill-advised? It seems that such a huge warning count makes it very hard for the compiler to tell you things. Well, doing a clean checkout of the master branch, noting N=number of warnings, then making your changes and comparing with N. At least that is what I did. It was not very popular, since no one ever tracked N on master at all. > I've generally found it quite practical to get warning counts to zero with some combination of fixing the issues and disabling warnings that have a poor signal-to-noise ratio. The one exception was /analyze builds. There I added filtering so that I could treat some warning types as fatal, and others would be reported on only when they were new. I completely agree that this is how it should be done. I vaguely remember that this is however quite complicated to achieve in the .NET ecosystem. Something about a library A being called in another project B respecting the disabled warnings of A when compiling A and B when compiling B, so you as a client could never disable warnings yourself (?). This was quite a while ago, and as I didn't work too much on A-type projects (only B-type projects), investigating it was never my responsibility. I just got told "It's not that simple" by the A-type employees.

ThePadawan 6y ago

> Curious. How do you know if you've added the 8001st warning that indicates that you did something ill-advised? It seems that such a huge warning count makes it very hard for the compiler to tell you things. Well, doing a clean checkout of the master branch, noting N=number of warnings, then making your changes and comparing with N. At least that is what I did. It was not very popular, since no one ever tracked N on master at all. > I've generally found it quite practical to get warning counts to zero with some combination of fixing the issues and disabling warnings that have a poor signal-to-noise ratio. The one exception was /analyze builds. There I added filtering so that I could treat some warning types as fatal, and others would be reported on only when they were new. I completely agree that this is how it should be done. I vaguely remember that this is however quite complicated to achieve in the .NET ecosystem. Something about a library A being called in another project B respecting the disabled warnings of A when compiling A and B when compiling B, so you as a client could never disable warnings yourself (?). This was quite a while ago, and as I didn't work too much on A-type projects (only B-type projects), investigating it was never my responsibility. I just got told "It's not that simple" by the A-type employees.