Eduard Witteveen wrote:
MMBase Coding standards: http://web.omroep.nl/mmbase/deprecation/coding> standards.htmlWhen will we have a definitive coding standard? The one you proposed is still not the standard.
It is for now. If you don't like them, propose your own changes and ask for a vote.
Personally I think member methods are more neat. Directly accessing variables may lead one to evade some essential initialization code.I do think that accessing inherited member variables could be done by accesing them directly, instead of accessing them though a method.
I don't see why you have such a problem with member methods (which can assist in adding context and validation) when you so insist on using classes for constants?
Protected member variables should be an exception, not the norm. Public member variables should only be used for container classes.
what is the policy about constants? Do use capitals only for them?
Yes. From the document : "Constants are all upper case and should be defined as static final."
Separate classes sound cool but they do use more resources and require more coding work. Not to mention you may get hundreds of these constant types. Not 100% against it but it is a lot of work to overturn the old code (though we may have to do that anyway).Furhtermore enumerations? Personally I like putting them in a separate class, so the range will be checked by the compiler (not the case when using int value's), and it is much clearer which value has to be used.
I generally turn to established libs to see how they do it, and in most cases they seem to use final static int values.
i.e: org.w3c.dom, java.sql, javax.naming, and the tomcat, log4j, Xerces, and Xalan packages
--
Pierre van Rooden
Mediapark, C 107 tel. +31 (0)35 6772815
"Never summon anything bigger than your head."
