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.