|more useful options|
The power of strict typo-checkingby tall_man (Parson)
|on Nov 06, 2004 at 15:50 UTC||Need Help??|
Scripting language designers face a temptation to drop all variable declarations. Variables can simply be created on first assignment. It seems so much easier than Java or C++ where everything must be declared before use. But there is a serious trade-off: misspelled variable names won't be caught until run-time. A restricted version of the language in which minimal declarations are required becomes necessary. Hence, Perl's "use strict" with "my" variables.
My first discovery of the value of this principle was in FORTRAN. In the old days people just started integer variables with I-N and float variables with other letters. But when I started using "IMPLICIT NONE" and found the power of compile-time typo-catching I never looked back.
Python and Ruby claim to be better-designed rivals to Perl, but neither of them has static checking for variable-name typos with the same power as Perl's. Variables on the left-hand side of assignments are particularly vulnerable to error. Python at least has PyChecker; Ruby has nothing.
Ruby users claim that everything can be caught by unit testing. That is a very poor idea because obscure paths through the code may be missed, and then a crash will happen during some crucial run later on. IMHO, unless Ruby comes up with a "strict" variant that allows some minimal static checking it will never be a serious rival for Perl for large projects.
Languages can do even more static checking without getting in the way. For example, OCaml does type inferencing based on the functions being applied to the variables. Explicit declarations are seldom needed for full compile-time type checking. The drawback is that operators have to be distinct by type: for example, "+." is used for floating-point addition and "+" for integer addition.
For me, Perl with "use strict" has a good balance between typo-catching power and simplicity of use. Additional optional "use stricter" checks might be worth looking into, for example doing the same sort of limitations on package-level variables.
This might produce an error or warning about creating a new package variable in code outside the package, instead of silently failing as it does now.