null [re: spec#]

Walter Bright newshound2 at digitalmars.com
Sun Nov 7 14:09:01 PST 2010


Simen kjaeraas wrote:
> You misunderstand. The idea is this:
> 
> void foo( ) {
>   Object p;
>   if ( m ) {
>     p = new Object( );
>     p.DoSomethingThatNeedsToBeDoneNow( );
>   }
>   // 20 lines of code here
>   if ( m ) {
>     p.doSomethingWeird( dataFromAbove );
>   }
> }

You're right, the real cases where this kind of thing occurs are much more 
complex. I just posted the thing boiled down.

And, of course, there's always a way to refactor the code to eliminate the 
spurious error message. But sometimes the result is as ugly as Pascal's efforts 
to prove you really don't need a 'break' statement in a loop.

The real problem with the spurious errors is that then people will put in an 
initialization "just to shut the compiler up." Time passes, and the next guy is 
looking at the code and wonders why x is being initialized to a value that is 
apparently never used, or worse, is initialized to some bogus value randomly 
picked by the long-retired programmer. I've seen code reviewers losing a lot of 
time on this issue.

In general, I am opposed to inserting dead code and unused values to get the 
compiler to accept the program. It makes the code harder to reason about. 
Everything in the code should have a purpose that goes towards understanding the 
code. If there's:

    int x = 0;

then it stands to reason that:

1. 0 is a valid value for whatever x is subsequently used for
2. this value of x is actually used

When both of these are false, it is obfuscation and counterproductive.


More information about the Digitalmars-d mailing list