Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Even forcing an explicit initializer doesn't actually solve the
problem - my experience with such features is programmers simply
insert any old value to get the code to pass the compiler, even
programmers who know it's a bad idea do it anyway.
I think you're starting to be wrong at the point where you don't
realize that many bugs come from references that people have forgotten
to initialize. Once you acknowledge those, you will start to realize
that a reference that must compulsively be initialized is valuable.
The problem is it's worse to force people to provide an initializer.
You aren't forcing them. They decide for themselves. They determine
whether it's appropriate for a particular variable to be null.
You can achieve the same goal through contracts. However, this is much
more verbose -- enough so that you'll only add these contracts when
hunting down a bug. And if you have an array of things
It isn't a theoretical problem with providing bad initializers just to
shut the compiler up. I have seen it in the wild every time some manager
required that code compile without warnings and the compiler warned
about no initializer.
C# requires that every variable be initialized before use. You know how
often I get such an error? Maybe once for every 100 hours of coding.
It's mainly for cases where I expect an integer to be initialized to 0
and it's not. You know how often I provide a bad initializer to shut the
compiler up? Never.
This is partially because C#'s compiler has good flow analysis. It's
mostly because:
- I declare variables where I use them, not beforehand.
- I often declare variables via IDE commands -- I write the code to
fetch or calculate a value and assign it to a variable that doesn't
exist, and the IDE fills in the type and declares it in the correct place.
- I usually don't have more than four or five local variables in a
function (often no more than one or two). Out of 300KLOC, there are a
few dozen functions that break this rule.
DMDFE functions are often long, complex, and have many local variables.
I see how this would conflict with your coding style. You would have to
add a few question marks for each function, and then you'd be done.
DMDFE is ~60KLOC, but you could probably switch it over to this type
system without structural changes to any function in a couple days.
