If you have no code using it now, I'd suggest continuing that. If your codebase uses it, continue that.
The biggest thing about coding style is consistency. If you have nothing to be consistent with, then the language vendor's recommendations are likely a good place to start.
It's a blend of coding styles. One school of thought is to preface private members with an underscore to distinguish them.
setBar( int bar)
{
_bar = bar;
}
instead of
setBar( int bar)
{
this.bar = bar;
}
Others will use underscores to indicate a temporary local variable that will go out of scope at the end of the method call. (I find this pretty useless - a good method shouldn't be that long, and the declaration is right there! So I know it goes out of scope.) God forbid a programmer from this school and a programmer from the memberData school collaborate! It would be hell.
Sometimes, generated code will preface variables with _ or __. The idea being that no human would ever do this, so it's safe.
"Bad style" is very subjective. If a certain conventions works for you and your team, I think that will qualify a bad/good style.
To answer your question: I use a leading underscore to mark private variables. I find it clear and I can scan through code fast and find out what's going on.
(I almost never use "this" though, except to prevent a name clash.)
The reason people do it (in my experience) is to differentiate between member variables and function parameters. In Java you can have a class like this:
public class TestClass {
int var1;
public void func1(int var1) {
System.out.println("Which one is it?: " + var1);
}
}
If you made the member variable _var1 or m_var1, you wouldn't have the ambiguity in the function.
Personally, I think a language shouldn't make rules about coding style. It is a matter of preferences, usage, convenience, and concept about readability.
Now, a project must set coding rules, for consistency across listings. You might not agree with these rules, but you should stick to them if you want to contribute (or work in a team).
At least, IDEs like Eclipse are agnostic, allowing to set rules like variable prefixes or suffixes, various styles of brace placement and space management, etc. So you can use it to reformat code along your guidelines.
Note: I am among those keeping their old habits from C/C++, coding Java with m_ prefixes for member variables (and s_ for static ones), prefixing Booleans with an initial b, using an initial uppercase letter for function names and aligning braces... The horror for Java fundamentalists! ;-)
Funnily, that's the conventions used where I work... probably because the main initial developer comes from the MFC world! :-D
Here's a link to Sun's recommendations for Java. Not that you have to use these or even that their library code follows all of them, but it's a good start if you're going from scratch. Tool like Eclipse have built in formatters and cleanup tools that can help you conform to these conventions (or others that you define).
It's nice to have something to distinguish private vs. public variables, but I don't like '_' in general coding. If I can help it in new code, I avoid their use.
I happen to like leading underscores for (private) instance variables. It seems easier to read and distinguish. Of course, this thing can get you into trouble with edge cases (e.g., public instance variables (not common, I know) - either way you name them, you're arguably breaking your naming convention:
private int _my_int;
public int myInt;? _my_int? )
As much as I like the _style of this and think it's readable, I find it's arguably more trouble than it's worth, as it's uncommon and it's likely not to match anything else in the codebase you're using.
Automated code generation (e.g., Eclipse's generate getters and setters) aren't likely to understand this, so you'll have to fix it by hand or muck with Eclipse enough to get it to recognize it.
Ultimately, you're going against the rest of the (Java) world's preferences and are likely to have some annoyances from that. And as previous posters have mentioned, consistency in the codebase trumps all of the above issues.
I don't think using _ or m_ to indicate member variables is bad in Java or any other language. In my opinion, it improves readability of your code because it allows you to look at a snippet and quickly identify out all of the member variables from locals.
You can also achieve this by forcing users to prepend instance variables with "this", but I find this slightly draconian. In many ways it violates DRY because it's an instance variable. Why qualify it twice?
My own personal style is to use m_ instead of _. The reason being that there are also global and static variables. The advantage to m_/_ is it distinguishes a variable's scope. So you can't reuse _ for global or static and instead I choose g_ and s_ respectively.
There is a reason why using underscores was considered being bad style in the old days. When a runtime compiler was something unaffordable and monitors came with astonishing 320x240 pixel resolution it was often not easy to differentiate between _name and __name.
