[Mulgara-dev] Style guide

Paul Gearon gearon at ieee.org
Fri May 18 20:41:06 UTC 2007


On 5/18/07, Life is hard, and then you die <ronald at innovation.ch> wrote:
> I tend to think you _have_ adhere to the style given, whether you like
> it or not.

I agree with you here.  My point here is to find a style that everyone
will agree to (hopefully that they like).... and then set it in stone.
 :-)

> And from that perspective I think it's a very bad idea to
> allow two different bracing styles - choose one and stick to it,
> period. I'm quite opinionated when it comes to coding, but even I've
> managed to adjust to different styles in different projects ;-)

In any normal project I'd have taken this approach already.  Sun's
standard for using braces in Java is almost the same as the standards
in Linux kernel programming (which I've also spent a lot of time
doing), and I would have loved to mandate it.  In fact, with the
exception of some of the reformatting that went on (I don't know who
did this) then you'll find that almost all of the code follows the
convention of opening braces at the end of a line, instead of on a new
one.  So this would have been a easy thing to require.

Besides that I *hate* reading code where opening braces are on a
following line.  :-)

However, "back in the day" when the original standard was written,
this was the ONE thing that divided the company in two.  Each side was
as passionate as the other.  Since we were egalitarian, and we wanted
to see everyone being as creative as possible, the decision was made
to allow both styles.  Crazy, I guess, but I'd have hated to be on the
wrong side of this decision, and I can have sympathy for the other
side if it had gone against them too.

(Remember, this has been as much a passion and hobby for us as it was
a professional gig.  Making programmers happy was a big deal).

Anyway, that's my justification for maintaining the status quo.  I'd
prefer to require one style over the other, but I won't mandate it
unless there's consensus.

> As to my personal likes/disklikes on coding styles, I agree with most
> of the stuff, except:
>
>  - I'd make space after keywords a MUST - this really helps in
>    visually distinguishing between method calls and other stuff (sure,
>    syntax coloring goes a long way here too).

Again, trying to keep it flexible.  But if you ever see me not putting
a space after a keyword, you have permission to hit me.  Hard.  :-)

>  - The "don't align the = in declarations" is weird - never seen
>    anybody dislike that before. But whatever.

It stood out for me too when I saw it, hence I remembered to put it
in.  I usually don't do make these alignments myself, except maybe
years ago if it were for a big set of related constants when writing
in C/C++.  However, since every constant gets its own Javadoc, I have
no temptation to do it here.

The only reason it's ever bugged me is when you need to add a new item
to the list of things being assigned, and it goes out wider than the =
sign.  Reformatting everything can get annoying, and there's no real
point.  As the original author said, "We're not writing COBOL".  (Yes,
that line was from the original author.  I've never written COBOL,
though I have some vague memory of there being alignment rules).

>  - Wildcard import should be disallowed. Period. It's a litle more
>    work to write, but it helps in avoiding conflicts and in easily
>    finding out where something is imported from (even for the java
>    packages).

I don't really mind since both Eclipse and IntelliJ do this for you
(and don't do wildcard imports).  I also like seeing EXACTLY what is
being used (and having the IDE tell me what is no longer in use).

However, I can see the desire to say java.util.* instead of:
import java.util.Set;
import java.util.HashSet;
import java.util.TreeSet;
import java.util.List;
import java.util.LinkedList;
import java.util.Map;
import java.util.HashMap;
import java.util.Collection;
import java.util.Arrays;

.... and so on.  Basically, I don't mind when other people want to use
* so long as it's under "java".  I suppose I like the idea of keeping
that option open for myself as well.... just in case.  :-)

But I have no real objection to requiring explicit imports.  Does
anyone else have something to say on this?  Yay?  Nay?

> Other than that, good stuff.

Thanks.

As I said, please let me know if you have any more rules, or any rules
you think should be changed/removed.  I'd particularly like to hear if
people agree or disagree with Ronald's points.

Paul



More information about the Mulgara-dev mailing list