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