Joel has a new rant about Hungarian notation and exceptions. In it, he outlines the principle that you should code in a manner that makes bad code more apparent. He uses an example of passing string values that must have special formatting in some instances and not others (safe string variable, sValue, and unsafe string variable, usValue). As usual, he goes step-by-step to slowly improve a bad situation. While he generally surprises me by going further than I can imagine with techniques to clean up the code, this time he stopped too soon.
He argued that Hungarian notation would alert programmers when they attempt to copy a normal string variable to a location that requires a formatted string variable (usValue = sValue, wrong). But in his frenzy to praise Hungarian notation (offering up yet another retelling of the history of it) and complain about poor operator overloading (hint: it's bad) he failed to provide a real solution to the problem.
Yeah, tagging variables with clues about their appropriate use is nice, but why not just create classes that forbid inappropriate use. Instead of staying in the realm of data error, use your compiler to notify you of errors.
class String {...};
class FormattedString {...};
String value1;
FormattedString value2;
// This won't compile.
value1 = value2;
Tada. Am I missing some other point he was trying to make?
I think he's trying to create a solution for a problem that doesn't exist. All of his issues can either be addressed by using better coding techniques, or by using a more intelligent IDE that is language aware.
Posted by: Titus Barik at May 13, 2005 4:03 PMI agree that he over-emphasizes bad techniques to get his point across, but I have to say that IDE features should be considered only as last resorts when designing code. Whenever possible, we should solve the problem within the domain of the language itself (which is the lowest common denominator). IDE features are meant to simplify and expedite development. Language techniques clarify and improve the code itself.
He references the limitations of Intellisense and rightly points out that it can never save you from data (run-time) errors. In fact, it never saves you from syntax errors either. It merely helps the developer to more quickly orient themselves within unfamiliar code. Only techniques within the code (shorter functions, data encapsulation, etc.) can limit or eliminate problem code.
Why can it not help you from syntax errors? The Java editor that I use, for example, tells me when I forget to add a semi-colon, or when I fail to surround a checked exception with a try catch block. It can tell me as I'm typing whether the object I'm adding to a genericized list is valid, or dynamically add an import statement when I use a class and forget to do it myself. It can tell me when there is an argument mismatch or when the types I'm passing to a function don't match the types that it expects. It can tell me that I'm erroneously calling a private method of another class by underlining it in red squiggles. It can tell me when I'm using a deprecated class by placing a strike-through through it.
Many of these are done using the reflection mechanisms of Java, without having to compile to determine these errors. And consequently, all of these things are caught without having to even compile the program.
An IDE is not necessarily a last resort. For example, in Java, a lot of people like to complain because the LHS and the RHS of object instantiation is nearly identical, and they don't like the verbosity and the extra typing (HashMap h = new HashMap()). But this is not a fundamental language problem. A good IDE completes the right hand side of the expression for you, or at least offers suggestions to autocomplete.
I completely agree with you that an IDE is not a substitute for good coding practices. Using design patterns when appropriate, ensuring concurrency and immutability on data structures, and so on, are all good practices that takes experience to use -- not an IntelliSense IDE.
But I think what I'm trying to say is that people often try to blame a language for its shortcoming, when those things aren't shortcomings at all with an appropriate IDE. Not having assertions in Java was a shortcoming until version 1.4. Having to re-write interface JavaDoc comments after implementing an interface is not.
It's late, so I'm not entirely coherent, and I don't know as many big words as you, but I hope that some of what I said makes sense. :-)
I just realized that some of the things that I said above involve semantic errors, not syntax errors. Oops.
Posted by: Titus Barik at May 17, 2005 12:20 AMSyntax, semantics, whatever. I understood what you meant. Good point. I was (somewhat wrongly) putting all language issues on the compiler. I think I see those IDE tools that subsume syntax checking as merely suggestions--they can nag you but you can still type something else. The Java IDE I use will flag a pre-compiled file as good/bad, and the VB IDE will (annoyingly) message-box me if I move the cursor off of an incomplete statement (whereas my intention is to copy the completion of the statement from another line). I was incorrectly using the compiler as a metaphor for the language. And although it is a complete metaphor for the language, the IDE is overlapping more-and-more into that domain.
But I think ultimately we're saying the same thing.
(Oh, and I was up late working, so no big words.)
Posted by: sstrader at May 17, 2005 8:30 AM