Null references (oh no, not again!)

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:gonthc$2ump$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
>> news:gonnf4$2mnj$1 at digitalmars.com...
>>>> The code is bug-ridden. It's exactly the kind of maintenance nightmare 
>>>> where you change one line and 1000 lines below something crashes.
>>> It does occur in various forms. I know this from experimenting with flow 
>>> analysis. The problem with saying it's "buggy" is then the programmer 
>>> throws in a dead assignment to "fix" it rather than refactor it.
>>>
>>>
>>
>> If someone has code like that than the main issue is that it needs to be 
>> refactored. Neither the current status of D, nor "perfect" flow-analysis 
>> would do anything to force, or even nudge, the programmer into doing that 
>> refactoring. So if C#-style analysis doesn't force the proper refactoring 
>> either, so what? At least attention will get called to it and the 
>> programmer will at least have the *opportunity* to choose to fix it. And 
>> if they choose to do the dead-assignment hack, well, the code's already 
>> crap anyway, it's not like they're really all that worse off.
>
> This is the same argument for mandatory exception specifications that Java 
> had. Bruce Eckel wrote a fascinating article about it, showing that even 
> the experts who denigrated and dismissed the "bad style" of the quick and 
> dirty fix, used it themselves. The excuse was always "I'll fix it later" 
> and of course it never got fixed.
>
> We could debate what good style is and is not, but I think we can agree 
> that the ideal language should make it easy to do good style, and more 
> effort to do bad style, because programmers will naturally follow the path 
> of least resistance - even the ones that know better.
>
> That's why php is so popular, yet reviled <g>.

First of all, Java's checked exception system is a far cry from what we're 
advocating here. That thing basically amounted to a manditory full and 
complete redundant manual documentation of all exception behavior of any 
code that ever touched any other code that used the checked exception 
system. It's no wonder people side-stepped it. What we're talking about here 
is an occasional tweak to the types of code that are already prone to hiding 
"use-of-uninited-ref/var" errors anyway, and no cascading effects. That's 
not even in the same ballpark.

Typical C# code would seem to agree with me on this. Even if there is an 
occasional kludge to circumvent proper initialization, people just don't 
typically circumvent initialization-checks in C#, it really just doesn't 
typically happen. After all, improper initialization in C# requires the 
programmer to actively create a kludge, but in D all it takes is a trivial 
mistake (and because of that, C# code is much less likely to have improper 
initialization than D).

As far as the idea of "easy to do good style, harder to do bad style", that 
only serves to support my argument. Omitting compiler checks for 
"potential-use-of-uninited-ref/var" makes it *very* easy to use a 
variable/reference that you haven't properly initialized (and like someone 
else said, T.init is not always the proper initial value for whatever you're 
doing). But when you put those checks in, even if the programmer kludges 
their way to compliance (which, going by C#, is fairly uncommon anyway), 
it's not as if they're any worse off.