Hello all, I've got a couple of easy questions. The first involves naming conventions for class members. Do any of you use some sort of prefix or suffix to indicate your class variables? I'm used to using a _ pre/suf-fix to mark my members in C++, and without them I tend to lose class members among local variables when looking at code. However, Sun seems pretty anal about their coding conventions and I know the JLS says don't use _ as the first character of a member name, so I'm not too sure what to do about this. Or does it just not matter? And how about imports? When do you stop listing individual classes in a package and start using *? I tend to like to import each class individually, but this can get out of hand sometimes. Any recommendations? Thanks and regards, Jay
Breaking Sun's conventions on naming sounds like an automatic failure to me. If you are coming from a c++ background, the java conventions might look odd to you, but once you get used to it, you'll see that for the most part, java code has a consistent look and feel, which makes it easier to pick up and maintain other people's code. So there is a genuine benefit to it Regarding imports, it's up to you. The compiler will only pick up the classes it needs to import anyway, so there is no performance impact. Whatever you feel makes you code the most readable, I guess.
Joined: Aug 09, 2003
Hello James, I am definitely agreed that I shouldn't do anything that the JLS says not to do, such as starting a name with '_', but it doesn't say anything about using a '_' as a suffix. Incidentally, I am from a C++ background, and I like the '_' suffix since it allows me and automated tools to quickly pick out where member variables are being touched. I find that when looking at Java code (even my own) it takes a bit longer for me to get things, since I have to look up which variables belong to a class. (I know a code browser helps, but even then you've got to focus your attention somewhere other than the code for a second.) Is there some sort of Java convention about this same thing? I've seen "my" used to mark members sometimes. Thanks and regards, Jay
It's been stongly hinted in the past, by people in a position to know, that candidates can lose points for failing to follow Sun coding standards. The ones that are linked to from Sun's main J2SE documaentation page. Now my own opinion is that Sun has done a very poor job of ommunicating this fact (if indeed it's still correct) in my own instructions. The client ("Bodgitt & Scarper") did not specify anything at all about coding standards. (If they did, it would have almost certainly overridden Sun's standards for our purposes here.) But they did supply one code fragment - the Data.java file. (Or DBAccess.java in some assignments.) Normally I would advocate following whatever style the customer is using, provided they have a consistent style. But the coding style in Data.java is abysmal, an indication that the people at Bodgitt & Scarper wouldn't know good coding style if it came and bit them on the butt. So frankly just about any consistent style would be an improvement over B&S. All other things being equal - Sun's style seems like a good option. And since it's been hinted that Sun's graders are, well, unjustifiably obstinate on this point, that's even more reason to do it. Is there some sort of Java convention about this same thing? I've seen "my" used to mark members sometimes. Not a standard one, no. Some shops religiously use "this.foo" if foo is a member variable, even if the this is implicit in many contexts. Some advocate creating getters and (if appropriate) setters, and accessing member variables only using the getters/setters. (Except within the getters/setters themselves.) Some use "my" or an underscore. Most I've worked with don't require any of these techniquest, and Sun's standard agrees with this. Plenty of IDEs are able to keep track of member variables vs. local variables. And my own personal preference is to keep all my methods short enough that it's really easy to see what variables have been declared locally; anything else must be an instance or class variable. On a loosely related note, I'm a big fan of using immutable classes and final variables wherever possible, in order to simplify the task of tracking changes in a variable. (Especially in a multithreaded environment.) Certainly many things can't be represented with immutable classes or primitive finals. But for any new class or variable you create, consider making it immutable or final. If you can, it cuts down on the things to worry about later; if you can't, then go ahead and make it mutable.