declaration of variables?

[André Jonsson]

Jp Calderone wrote:
>>That may be the case, but it's better/easier if the error/warning occurrs 
>>when the program i compiled (run-time or otherwise) 
> 
>   No.  You think it is better or easier.  Many other people disagree.

Maybe so, but I know many also agree with me, so it's not really a clear-cut case.


>   A good set of unit tests will catch this error any time it comes up. A
> good set of unit tests will also catch many *other* errors that variable
> declaration won't.  If you don't have good unit tests, it might be time to
> consider writing some.

I haven't done many no, so that's probably the case. I still think that receiving 
information about an error sooner is better than later. Having the privilege of using 
the Java environment IDEA, you get spoiled with those kind of things. It informs you 
about a whole bunch of these things without even having to compile the code. I'm 
pretty certain that has saved me a *lot* of time.

And I do think that declaring a variable isn't that much of a hassle, atleast not of 
the magnitude you (and others) make it out to be. Chasing down "strange" errors is.


>   As a Python programmer of 5 years, I can give my personal experience:
> typos in names haven't cost me anything more than a dozen lost seconds once
> every few weeks.  On the other hand, having to type declarations for every
> variable I use would cost me at least a hundred times more time, on a
> regular basis.

Funny, I think it's the other way around. I can't claim 5 years of Python programming 
experience though, but I do have experience with several other languages (during my 
pre-python era), and in these kinds of "dynamic" languages it mostly is an annoyance.


>>than when the program execution gets to the spcific error, in which case
>>it may, or may not, be detectable.
> 
>   I don't understand what this even means.  If the error isn't *detectable*,
> it obviously isn't even an error.

Hmm, how about this example: if a given function sorts some list, if there is an 
error in there that doesn't cause a run-time error. How is it possible to detect this 
without having to write the whole routine once more and compare the results? (which, 
of course, is an error-prone process).

But then again, I don't have much experience with unit-testing.


It could probably be the case that it is a state of mind whether it is a problem, or 
a desired behaviour.


/André