Names
-
I don't disagree with you, or the use of helpful hints like you suggest. But whilst your suggestion (and indeed hungarian notation etc in general) provides useful prompts and hints to the coder it doesn't address type safety and in fact can be counterproductive in non typesafe languages: I hit this kind of thing a lot in an elderly VBA codebase that I maintain and develop for a client. GUIDs can be represented (validly) as either a string (in 3 different formats FFS!) or as a BYTE array. When reading a GUID from SQL Server into a table and thence into a form and onwards into code you usually get a string, but sometimes (I presume depending on the temperature of Bill Gates' shower at the time the code runs) you get a BYTE ARRAY - all of these can appear in the variable you assign them to if it's a Variant, and you can only find out which one you get by testing the type of the variable after assignment, or when an exception is raised on use! However, if you are attempting to assign the GUID to a string and it arrives as a BYTE array it doesn't cause an exception, instead you silently get a GUID consisting of '??????' 8) I have spent many many hours tracking down strange bugs caused by this behaviour. If (as I have discovered in code I inherited) errors have been disabled so that (unless the error is actually fatal) code continues with the statement after the one where an error occurs, you are falling down a rabbit hole with no bottom! Note that although you may get a BYTE array GUID, this cannot be assigned to a GUID column in a table, so you have to convert it to a suitably formatted string (and the formatting acceptable depends on whether the table is local or on the SQL server). Working on code like this when it is full of incredibly long-winded, supposedly 'typed' variable and function names is just adding insult to injury! 8)
I know what you mean. I've seen my share of legacy garbage. And it doesn't stop in front of the big names. I still remember one project where I tried to put a thin layer between our embedded application and embedded Windows (back then still called CE), in an attempt to port it to another embedded OS. I stopped when I realized just how full the Windows APIs were with inconsistencies, including a couple of obvious bugs (well they became obvious when I worked on it - they weren't obvious at all when you looked at the individual parts of the API in isolation :~) Everybody makes mistakes, and the older the systems are, the more mistakes you'll find. That's just the way things are, and my own code is no exception. That doesn't invalidate my statement though: if used in the way I presented above, even if used inconsistently, it will increase the likelyhood of discovering semantic errors. That said, I wouldn't use hungarian notation for any of the examples you brought up: I agree with you that in those cases it served no meaningful purpose. I've found the article that was at the back of my mind all the time when posting here: Making Wrong Code Look Wrong – Joel on Software[^] I really like how Joel explains the do's and don'ts of hungarian notation, and how to use it correctly.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I know what you mean. I've seen my share of legacy garbage. And it doesn't stop in front of the big names. I still remember one project where I tried to put a thin layer between our embedded application and embedded Windows (back then still called CE), in an attempt to port it to another embedded OS. I stopped when I realized just how full the Windows APIs were with inconsistencies, including a couple of obvious bugs (well they became obvious when I worked on it - they weren't obvious at all when you looked at the individual parts of the API in isolation :~) Everybody makes mistakes, and the older the systems are, the more mistakes you'll find. That's just the way things are, and my own code is no exception. That doesn't invalidate my statement though: if used in the way I presented above, even if used inconsistently, it will increase the likelyhood of discovering semantic errors. That said, I wouldn't use hungarian notation for any of the examples you brought up: I agree with you that in those cases it served no meaningful purpose. I've found the article that was at the back of my mind all the time when posting here: Making Wrong Code Look Wrong – Joel on Software[^] I really like how Joel explains the do's and don'ts of hungarian notation, and how to use it correctly.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Thanks for that link - I've read a few of his articles in the past and found them helpful. So much to read - so little time! 8)
-
Thanks for that link - I've read a few of his articles in the past and found them helpful. So much to read - so little time! 8)
And having read the paper - I once again agree with what he says! I was a fervent adopter of C++ in its early days, but as the language developed and got harder and harder both to use effectively and read I gave up using it. (The fiasco of manipulators between versions 1,2 and 3 didn't help either!) (Neither did a commercially produced database library 'accidentally' passing parameters by value and not by reference - as per the documentation - which caused an amazing array of problems until I tracked down just what was going on! 8) ) Joel's example of what appears to be a simple multiplication is one of my pet peeves about C++ and the fact that in a complex class you can end up with what are effectively class globals that can be accidentally hidden by local variables if you are not very careful is another. Once it became harder to use C++ effectively than it was to solve the programming problems I was using it for, I gave up. As for exceptions, tracing back through 12 layers of exception handling to find out what is causing it is a nightmare - like he says useful for stuff that isn't mission critical, but a bottomless pit in difficult stuff.