> No, no, no, no, no!!!! Even Microsoft have given up on this practice > as being old-fashioned and causing confusion and making code hard to > read! > > Hungarian notation is a *terrible* practice! It makes code hard to > read and it makes maintenance *much* harder!
I think that really depends on who's doing the reading and what they're reading the code in. Actually, I'm certain of this. By way of explanation, I spent a good deal of the last two years writing an application in ASP/VBScript with Visual Basic COM objects. VBScript is a dynamic, weakly typed language. Visual Basic is for the most part as well, though it does support type declarations. However, to interact with ASP, you pretty much have to declare everything a variant at the interface level. One of the project requirements was that I use prefixes like str, bool, int, dbl, and obj. I was against it because I saw little value in it, and at the time, I personally found it more difficult to read. However, after using the notation for two years, I find it just as easy to read as anything else. Anyway, that's what the client wanted because it was a part of their company wide coding standards. So, I consented without argument. The only place I did not use the notation was on properties and methods of objects. None of their other apps were object oriented so I didn't feel I was violating their coding conventions. At some point, there was a decision to port the app to J2EE. The developers who ported the code were actually really happy 1) that I had used common object oriented design patterns throughout and 2) that I used the naming convention. The first is relevant only in that the two apps could be structured roughly the same. In regards to the second, according to the developers, the notation made reading the code and porting it much easier. In Java, you can look at the type declaration to find out the type. In VBScript, everything is a variant. Furthermore, VBScript lacks an IDE with a debugger (yes, I know one exists, but I've yet to find a mortal who has successfully gotten it to work). The same was more or less true for the Visual Basic COM objects. As I said, you pretty much have to use variants at every public interface. The one key difference here is that Visual Basic does have a (very nice) debugger. So, they could examine the code at runtime if necessary. But, for the most part, they didn't have to. The notation told them what the language/IDE/debugger didn't. Using the naming convention in Java didn't make as much sense. In the Java/C# "everything is an object" paradigm, notation really doesn't work. Yes, I know there are primitive types, but you don't pass a lot of primitives around and you have to declare the type when creating the variable, severely mitigating any benefits of using the notation. However, in a dynamic, weakly typed, procedural language without type declaration, a proper IDE, or a debugger (say, like ColdFusion) notation makes a lot more sense. That said, I still don't use it in my ColdFusion code. :) ColdFusion is much better at handling implicit data type conversions than VBScript/Visual Basic (not to mention it lacks the concept of a null). ColdFusion is also a pretty wordy language: it's hard enough as is to visually parse a block of ColdFusion code. Finally, the cfdump tag goes a long way towards making up for a debugger. So, going back to my original argument, I think the benefits to type notation depend on many, many factors. You simply can't make blanket statements one way or the other. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - RUWebby http://www.ruwebby.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188751 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
