Re: [Pki-devel] Automatic reformatting and code style
On 11/23/2011 02:57 PM, Ade Lee wrote:
instead of this (as in the Sun standard):
public class MyClass {
...
}
preferred, closer to K&R, you can more lines of code on the screen if
you don't allocate one line just for a brace.
2. We require that interface names begin with "I". Sun
says nothing
about this. This is probably a good one to keep.
Using an initial character to declare a type was a bad idea over a half
century ago when Fortran was invented, but of course there were
justifiable limitations in the 1950's but those have vanished, oh let's
say 30-40 years ago.
Then some idiot at Microsoft came up with Hungarian notation, one of the
worst ideas I've ever seen. In a strongly typed language there is
absolutely no need to encode the type of the object in it's name, a
throwback to a bad idea in Fortran which diminishes readability for no
apparent useful reason.
Let's not encode the type in the name. The name should be self evident
and if you still can't figure out the type then look up it's declaration.
I also don't believe in declaring interfaces unless there is a need.
Excessive use of interfaces for which there is only one class
implementing the interface just makes the code more verbose and harder
to understand what's going on. The presence of an interface implies
there is some public sharing between objects. Can't tell you the number
of times I went looking for all the places an interface was used only to
discover it was just one self contained class, go figure.
3. We specify "no tabs". Sun says tabs are optional. We
should keep
this.
No tabs. Everyone has a different idea of what tab width should be and
if they aren't the same, which they never are, all you get is a jumbled
mess.
4. We say "Static methods should begin with a capital letter with each
subsequent new word in uppercase, and subsequent letters in each word in
lower case. Sun has no special treatment for static methods - ie. they
are treated just like other methods .. ie. beginning with a lower-case
letter.
5. We do have some guidelines for naming functions that go beyond what
Sun specifies - and also perhaps, beyond what eclipse can verify.
For example:
* Get and set methods should begin with "get" / "set" and return
the
appropriate object type.
* Boolean get methods should use "is" or "can" as a prefix, such
as
"isUndoable()" rather than "getUndoable()".
* Factory class names should include the word "Factory". Factory method
names should start with the word "Make."
* Methods for debug-only implementations should begin with "debug".
All good.
* Member variables should begin with "m". For example,
mMemberVariable.
Another incredibly annoying convention, see above rant about encoding
type information in a symbol name. Objects essentially can only have
member variables and methods, if someone can't figure out the difference
then prefixing it with an 'm' is the least of their problems :-)
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/