Fantastic exchange from DConf

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/10/2017 02:28 AM, H. S. Teoh via Digitalmars-d wrote:
>
> I'd much rather the compiler say "Hey, you! This piece of code is
> probably wrong, so please fix it! If it was intentional, please write it
> another way that makes that clear!" - and abort with a compile error.
>

In the vast majority of cases, yes, I agree. But I've seen good ideas of 
useful heads-ups the compiler *could* provide get shot down in favor of 
silence because making it an error would, indeed, be a pedantic pain.

As I see it, an argument against warnings is an argument against lint 
tools. And lint messages are *less* likely to get heeded, because the 
user has to actually go ahead and bother to install and run them.


>> That puts me strongly in the philosophy of "Code containing warnings:
>> Allowed while compiling, disallowed when committing (with allowances
>> for mitigating circumstances)."
>
> I'm on the fence about the former.  My current theory is that being
> forced to write "proper" code even while refactoring actually helps the
> quality of the resulting code.

I find anything too pedantic to be an outright error will *seriously* 
get in my way and break my workflow on the task at hand when I'm dealing 
with refactoring, debugging, playing around with an idea, etc., if I'm 
required to compulsively "clean them all up" at every little step along 
the way (it'd be like working with my mother hovering over my shoulder...).

And that's been the case even for things I would normally want to be 
informed of. Dead/unreachable code and unused variables are two examples 
that come to mind.

> The problem is that
> it's not enforced by the compiler, so *somebody* somewhere will
> inevitably bypass it.

I never understood the "Some people ignore it, therefore it's good to 
remove it and prevent anyone else from ever benefiting" line of reasoning.

I don't want all "caution" road signs ("stop sign ahead", "hidden 
driveway", "speed limit decreases ahead", etc) all ripped out of the 
ground and tossed just because there are some jackasses who ignore them 
and cause trouble. Bad things happen when people ignore road signs, and 
they do ignore road signs, therefore let's get rid of road signs. That 
wouldn't make any shred of sense, would it? It's the same thing here:

I'd rather have somebody somewhere bypass that enforcement than render 
EVERYONE completely unable to benefit from it, ever. When the compiler 
keeps silent about a code smell instead of emitting a waring, that's 
exactly the same as emitting a warning but *requiring* that *everybody* 
*always* ignores it.

"Sometimes" missing a heads-up is better than "always" missing it.


>> C/C++ doesn't demonstrate that warnings are doomed to be useless and
>> "always" ignored. What it demonstrates is that warnings are NOT an
>> appropriate strategy for fixing language problems.
>
> Point.  I suppose YMMV, but IME unless warnings are enforced with
> -Werror or equivalent, after a while people just stop paying attention
> to them, at least where I work.

So nobody else should have the opportunity to benefit from them?

Because that's what the alternative is. As soon as we buy into the 
"error" vs "totally ok" false dichotomy, we start hitting (and this is 
exactly what did happen in D many years ago) cases where a known code 
smell is too pedantic to be justifiable as a build-breaking error. So if 
we buy into the "error/ok" dichotomy, those code smells are forced into 
the "A-Ok!" bucket, guaranteeing that nobody benefits.

Those "X doesn't fit into the error vs ok dichotomy" realities are 
exactly why DMD wound up with a set of warnings despite Walter's 
philosophical objections to them.


> That's why my eventual conclusion is that anything short of enforcement
> will ultimately fail. Unless there is no way you can actually get an
> executable out of badly-written code, there will always be *somebody*
> out there that will write bad code. And by Murphy's Law, that somebody
> will eventually be someone in your team, and chances are you'll be the
> one cleaning up the mess afterwards.  Not something I envy doing (I've
> already had to do too much of that).

And when I am tasked with cleaning up that bad code, I *really* hope 
it's from me being the only one to read the warnings, and not because I 
just wasted the whole day tracking down some weird bug only to find it 
was caused by something the compiler *could* have warned me about, but 
chose not to because the compiler doesn't believe in warnings out of 
fear that somebody, somewhere might ignore it.