Using an underscore to mark a variable as being limited in scope in some fashion (private to the method, or class, or module, or being a field and not a local variable, etc) is no different from using a letter on any other symbol to do so. In other words, it's scope hungarian notation.
All hungarian notation is a bad idea. The aim of hungarian notation of any sort is twofold: (A) to succinctly convey a property deemed important _EVERYWHERE_ the variable is used. It's instantly visible. (B) Affect auto-complete IDE features. [A] (convey properties) doesn't really work because there are far too many properties. There's type (iAge is an integer, dAge is a double), there's lex scope (_foo is a field, foo is a local), there's runtime scope (sFoo is a static field, fFoo is an instance field), there's mutability state, there's nullity state, and there are a bajillion other states we could reasonably track with hungarian. Usually the importance of any of these is overstated, and only for a select few such properties, being reminded every single time you look at it is relevant. Either way we have a boatload of symbolic codes here which a programmer needs to remember and which, and this is very important, nobody really standardized on. Thus, using this feature means either you're going to choose an arbitrary state (i.e. with this underscore, apparently whether its local or field), and ignore all other ones. Whatever argument you can come up with in favour of your own underscore immediately invalidates it as you forgot all those other states. Alternatively you try to cover all of them but that's not standardized and would result in something like: private static int _smiqnAge; With each symbol before "Age" has some meaning. From gut instinct I'm going to conclude there's no way that's a good idea, though I admit I've not tried it. Virtually all such properties have something in common: An IDE can trivially figure out which is which. Thus, if its important for you to, say, spot statics at a glance, wherever they are used, configure your IDE to render them bold, italics, green, red, or blinking for all I care. Point is: Now it's _YOUR_ personal preference and thus there's no need for standardization (though that would be useful - it's just not necessary, unlike when using hungarian). You can also turn it off when its just gumming up the works and making it difficult to see the forest for the trees. All hungarian notation also annoys and corrupts refactors. Fortunately IDEs (with java) never get refactors wrong, but IDEs so far don't really support fixing prefixes properly (mirroring the argument of: "Hungarian is nice because my source control diff viewer doesn't colour my java stuff" - either way we've got tools that need work. I vote we fix the source control diff viewer instead!), and all those renames are going to cause quite a splash in the commit logs. § Then there's [B]: Affect autocomplete. In some limited cases this helps, but there are just as many cases where it hurts: When I'm thinking of "there's some integer here", and I'm using type-based hungarian, I can type "i", hit space, and see mostly just integers. Cool! But what if I'm thinking: "There was some field I can use here, don't remember the type?" Now I have absolutely nothing. If we go the route of encoding it all in hungarian that's no use at all as there's an order to these things. Only the property that is first in the order can be used to filter the autocompletes. In fact, with hungarian if you know the type name you CANT use that for auto-complete, so while in theory hungarian can help here, in practice it just hurts auto-complete. Identifier name is as good a property as any to choose. I bet if I did some empirical study of which property one is most likely to remember, name wins, which means using no hungarian (or postfix hungarian) wins. If this kind of lookup was actually important, instead of a trivial detail that nobody actually cares about, IDEs would long ago have invented ways to do autocomplete lookups in ways other than "type the first few letters of the identifier". There's no practical reason eclipse lacks the ability to, say, list all accessible identifiers of type 'int' at some point in your code. It doesn't exist because nobody wants it. Nuff said, really. TL;DR: underscores (in java at least) are a form of hungarian notation, and all hungarian notation sucks worse than the alternatives. Only where hungarian is used to convey information that cannot be conveyed in the language in any way or form can one make an argument for them, and python's _ = private convention is one such example. In java one could try and convey, say, nullity this way, but I'm guessing annotations and just extending the type system is a much more sound way to get there. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
