G
Guest
Our company is rewriting our product in .NET. The old product is in PowerBuilder, which is heavy on Hungarian notation. We are approaching the time where we have to finalize naming conventions for everything publicly exposed in our API
There are two camps -- the Hungarian camp and the "Readable English" camp. I am in the latter. Like Microsoft's official recommendations for .NET, I have seen the light. Readability is what matters when looking at someone else's code; knowing it's scope, datatype and member type (property, method, event, etc) can be determined both from the type of name (noun, verb, adjective) and by moving the mouse over it in Visual Studio. Hungarian notation is painfully hard to read, and seems to encourage cryptic abbreviations in the non-prefix part of the name as well
The Hungarian camp has lost ground due to the ever-improving Intellisense features in Visual Studio. There is no longer any need to rely on unreliable voluntary prefixing when reliable Intellisense is always there (and no, programmers do not pour over huge paper printouts anymore ...
The final bone of contention is over the risk of member name collisions. The Hungarian camp is balking that unless we use ugly prefixes that no one else will use, we run the risk of .NET or 3rd party base classes adding members (possibly methods, but more likely properties and events) with names we've already used in our subclass. The collission may simply hide the base class's member, or if the return types don't match, it won't even recompile. In either case, if the users of our API want access to the new base class member, we'll have to rename our member (we can get at it inside the subclass using "base.", but outside the subclass that's not possible). All this is assuming that our member and the newly added base class member are indeed conceptually different, so that we can't just retire our member or wrap the base member with ours and let the API users see it as one
How often do member name collisions really occur? If we weren't creating an API for use by customers, this would be no big deal for us to just rename our member -- just do a search & replace on our own code in-house. I still don't see it happening that often that our customers would be burdened if they had to do the same
If anyone has any experience with this, feedback would be appreciated. If we can't come up with actual case studies, then the Hungarian camp will win out of fear mongering (they hold the company's purse strings, too, so they don't have to argue that well ...
There are two camps -- the Hungarian camp and the "Readable English" camp. I am in the latter. Like Microsoft's official recommendations for .NET, I have seen the light. Readability is what matters when looking at someone else's code; knowing it's scope, datatype and member type (property, method, event, etc) can be determined both from the type of name (noun, verb, adjective) and by moving the mouse over it in Visual Studio. Hungarian notation is painfully hard to read, and seems to encourage cryptic abbreviations in the non-prefix part of the name as well
The Hungarian camp has lost ground due to the ever-improving Intellisense features in Visual Studio. There is no longer any need to rely on unreliable voluntary prefixing when reliable Intellisense is always there (and no, programmers do not pour over huge paper printouts anymore ...
The final bone of contention is over the risk of member name collisions. The Hungarian camp is balking that unless we use ugly prefixes that no one else will use, we run the risk of .NET or 3rd party base classes adding members (possibly methods, but more likely properties and events) with names we've already used in our subclass. The collission may simply hide the base class's member, or if the return types don't match, it won't even recompile. In either case, if the users of our API want access to the new base class member, we'll have to rename our member (we can get at it inside the subclass using "base.", but outside the subclass that's not possible). All this is assuming that our member and the newly added base class member are indeed conceptually different, so that we can't just retire our member or wrap the base member with ours and let the API users see it as one
How often do member name collisions really occur? If we weren't creating an API for use by customers, this would be no big deal for us to just rename our member -- just do a search & replace on our own code in-house. I still don't see it happening that often that our customers would be burdened if they had to do the same
If anyone has any experience with this, feedback would be appreciated. If we can't come up with actual case studies, then the Hungarian camp will win out of fear mongering (they hold the company's purse strings, too, so they don't have to argue that well ...