EJB and variable notation

[Mark Herschberg]

For the last few years, I have been using the "m_" convention. For those not familiar with it, you basically have all class variables start with "m_" For my fruit class, we would have the following:

public class Fruit {
   private int m_weight;
   public void setWeight(int weight) {
      m_weight = weight;
   }
}

Likewise, static variables are named starting with "s_" The main advantage is scope clarity. Within a method, I can determine if a particular variable has local scope, instance scope, or class scope. (Some also like it because IDEs alphabetize and this effectively puts all variables together.)
(For the record, this is not part of Hungarian Notation).
I've used this effectively for years. Unfortunately, EJBs, especially when used with IDEs are very unfriendly to this sort of convention. (I've heard JavaBeans are the same way.) What have others done? I'd hate to give up such a useful convention, but my EJB code is now half and half, greatly reducing the notational benefit.
--Mark

[Chris Mathews]

I also do not use the Sun Naming Convention for instance and class variables. I use an _ prefix.
Technically speaking this should not pose a problem because for the most part, do to the virtues of Encapsulation, it does not matter what we name our variables in EJB. This however is not the case with Entity Bean PK classes. The attributes of the PK classes are required to be public (correct me if I'm wrong), and therefore our notation must be cast out. This is also true of the Bean classes for CMP 1.1, but I hope nobody is still using CMP 1.1.
Besides, the PK classes, which we can make special cases, I don't see any reason why an alternative notation should cause problems.
When it comes to IDEs... now that is an entirely different matter. If the IDE is hindering your style then I would suggest using something that is less intrusive. I prefer IntelliJ IDEA, it does everything I need it to do (+ some) and it stays out of my way. What kind of problems have you encountered?
Anybody else have comments?
[ January 15, 2003: Message edited by: Chris Mathews ]

[Mark Herschberg]

I'm using JBuilder 8.0 Enterprise. I use to be a big JBuilder fan. But JBuilder has been screwing up all sorts of things with EJBs. For example, it keepts changing my findByPrimaryKey return values to null, for some reason). It also doesn't seem to correctly update interfaces. One of them is that when I add variables using the bean designer, it created methods based on the name, e.g. variablem_foo has a method getM_foo() which I don't like. In theory, I could rename the variables and methods, but with all the other problems JBuilder has given me, I am extremely hesitant to do so. JBuilder seems especially bad reconciling inconsistencies between the bean designer and the source code (e.g. changing the parameters of a method call in the source code only sometimes results in the change being reflected in the bean designer). I'm still too new with EJBs and too wnat to risk losing days dealin with this.
I guess I'll take solace in that it can be done, and I'll get more comfortable with JBuilder or find another IDE in the future.
Thanks.

--Mark

[Chris Mathews]

I used to use JBuilder quite a bit and I came across the types of annoyances that you mention. They are definitely not constrained to just the EJB realm. It was still much better than Visual Cafe(yuck!).
Personally, I always tried to avoid the Bean Designer like the plague. It seemed everytimeI used the thing, JBuilder took the opportunity to muck with my code.
My recommendation is to stay away from JBuilder's EJB Wizards if at all possible, that might allevate many of your problems. If you get a chance I would switch to completely building your project with ANT, but I realize since you are in smack in the middle of the project that you may not have time to do that. The big question is: Do you have time not to do it?
It doesn't help you now, but I suggest you give IntelliJ a try on your next project. It really is a great tool.

[Kyle Brown]

Personally, I've always despised the m_ thing. My feeling is that if your class or method is so long that you NEED to be reminded of the scope of a variable that you need to refactor your class or method!
Smalltalk (ahem, cough, Sun) naming conventions rule!
Kyle

[Peter den Haan]

I guess this is a religious issue. I, too, have something against prefixes, suffixes and other decorations -- as Kyle says, if you need them your method or class is probably too large or complicated.
In those rare cases where I feel the scope of a variable is unclear but no refactoring is indicated, I don't prefix with "m_" or "_" but with "this."
- Peter
[ January 16, 2003: Message edited by: Peter den Haan ]

[Chris Mathews]

Personally, I like making a distinction between fields and local variables. I feel that there are some definite advantages.

You can configure most IDEs/Editors to colorcode/highlight fields as opposed to local variables.

I find the distinction helps during refactoring, such as when determining whether a method can be extracted or moved easily.

The annoying self-assignment bugs become much more apparent. Though some IDEs handle this for us.

Frankly, I dislike having to litter my code with "this." Overall, I really don't care which code conventions are used in a project, as long as everyone is using the same convention and they are applied consistently.
[ January 16, 2003: Message edited by: Chris Mathews ]

[Thomas Taeger]

Originally posted by Mark Herschberg:
... all class variables start with "m_" ...
... Likewise, static variables are named starting with "s_" ...

Hi Mark,
after having used underscores for years, I finally stripped them off many years ago (in Pascal projects) because I got pain in my fingers, and all the underscores are painfull and time consuming to write.
In huge Java projects there is an even more important reason: Ease of refactorizing a huge project, including to globally search and replace class names and very often member names too - automatically over all files of the project:
Instead of m_classissimo I would at least call it m_Classissimo in all those cases where the variable just holds an instance of the class Classissimo and no further naming hints are needed. (Good naming for me is very important for readability and stability too).
When you have to rename all Classisimo declarations and members over the whole project one day, you will be glad to have UNIQUELY used the leading CAPITAL for the class name (standard in Java) and the member names after the leading 'm' (mClassissimo).
With problems of any click&paste whizards for rapid coding (for instance GUI whizards like VisualCafe or JBuilders bidirectional coding/viewing) I have never been concerned for long. I do not use Whizards because they produce uggly, lengthy (!) and hardly maintainable code similar to that of copy&paste.
Thomas.

[Mark Herschberg]

Originally posted by Peter den Haan:
I guess this is a religious issue. I, too, have something against prefixes, suffixes and other decorations -- as Kyle says, if you need them your method or class is probably too large or complicated.

Damn straight this is a religious issue (cackling... "Nobody expects Hungarian Notation!" "Go get the user-friendly Intergrated Development Environment." :-) Look at the reasons you two (whom I respect greatly, even if I don't always agree with you) gave. You basically said "if you need to do that, you're method is too long."
Now it may be true that long methods create that need, and that thus, this motivation is an indication of a problem. However, there are other reasons, too.
I'M LAZY!
I'm a very lazy programmer. I try to avoid thinking when possible (which is why I'm currently working at a business school :-). Three months from now I'll have to track a bug and look through my code. Like most programmers, I can barely recall what I did yesterday, let alone three months ago. So here I am, looking through a half dozen "foreign" classes. Anything I can do to make those easier to read saves me thinking, saves me time, and reduces the chances of misunderanding. I consider that enough value to justify this.
And speaking of "this"....

Originally posted by Peter den Haan:
In those rare cases where I feel the scope of a variable is unclear but no refactoring is indicated, I don't prefix with "m_" or "_" but with "this."

Hyprocracy! (Or sarcasm. Maybe both.) So you do practice this black art, you just just sacrifice to a different diety.
--Mark

[Guennadiy VANIN]

Originally posted by Peter den Haan:
guess this is a religious issue. I, too, have something against prefixes, suffixes and other decorations -- as Kyle says, if you need them your method or class is probably too large or complicated.

Having big classes is a performance issue (i.e. small classes deteriorate significantly performance).
Also working in big projects you do not have control over style of the others especially over huge bulk of the code created years ago. At my recebt jobs, I had classes code with thousands lines of code which I needed to use or just modify by one line. And what, due to small need, I should refractor huge existing for years applications? Either take religious for granted or be martyr.

[Kyle Brown]

Originally posted by Guennadiy VANIN:

Having big classes is a performance issue (i.e. small classes deteriorate significantly performance).

Horse hockey. Where did you get that notion? Do you have some proof to back that up or are you just repeating something you were told?
Kyle