[Pki-devel] Automatic reformatting and code style

[John Dennis]

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 at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/