Walter Bright wrote:
Sean Kelly wrote:
In a language like Java where basically every variable is a reference,
it can be a lot more difficult to figure out where a null came from.
I've never had this problem in code I've written either, but I've had
to maintain some Java code that was nearly impenetrable and this was
absolutely an issue.
I've found that variables are rarely written to, but often read. A grep
finds the handful of places where it is written to (a good IDE should
also provide this information much better than grep). There just won't
be that many places to look.
Say one variable is initialized at 4 points by different variables, some
are the same type and some are different types with an explicit
downcast. Now I have to consider a possible cast failure (the easy
case) and I also have to look to see where those 4 variables were
initialized, possibly introducing another 4 initialization points per
variable, and so on. It's entirely possible to do this, but I'm looking
at either inserting checks at an exponential number of locations and
then running once, or running and finding the offending initialization
then running again to find the preceding offending initialization, etc.
Even worse is when a container is involved, since they tend to have a
ton more points in the code where their contents are being altered or
rearranged.
There's one instance in a Java program I've worked on where I've seen a
variable be null that, from code inspection, should logically never be
null at that point. I'm sure I missed something subtle, but I'll be
darned if I know what it is.
This is drastically different from a C/C++ application where references
are the exception rather than the norm. D stands somewhere between the
two depending on programming style.
(I tend to use grep a lot on code, and so tend to write variable names
that are amenable to grep. If you use globals named "i", hope you have a
decent IDE!)
Same here. Without find/grep I'd have given up on programming long ago.
