I prefer 4 to 2 spaces because it makes the code easier to read. I
don't worry about nested blocks because if it becomes an issue then
that's usually a red flag that I'm writing or, worse, reading
spaghetti code.
I prefer the brackets on the next line because it makes the code
easier to read.
imho, the coding conventions from Geronimo were influenced by a long
standing formatting tradition started when BSD Unix was written. In
those days screen space was a premium and so issues such as
readability took a back seat to more pragmatic issues such as fitting
the function that you were writing on the screen. As someone who used
to write large bodies of code on punched cards I can happily say that
those days are, thankfully, over.
Having multiple coding conventions for this project, imnsho, is
ridiculous.
Regards,
Alan
On Feb 16, 2010, at 8:01 AM, Timothy Ward wrote:
I also prefer 2 spaces to 4, it saves a lot of space in nested blocks.
I would say, however, that I don't really believe in "house style"
when it comes to code formatting. It is entirely possible to format
code as an unreadable mess, but my experience has always been that
any "real" code is presented in a readable format. It may not follow
my exact personal preference, but I don't think that means it should
be changed. I agree that it's polite to follow the tab size already
in the file, which I believe is the case throughout the codebase,
even if there are some files that use 2 spaces and others that use 4.
Personally, I don't think there's a readability problem in the Aries
source and therefore I don't think that we need to establish code
formatting rules. Equally, it's not that important an issue and
definitely not worth starting an argument over!
Regards,
Tim
Date: Tue, 16 Feb 2010 11:46:26 +0000
Subject: Re: [DISCUSS] Code formatting
From: [email protected]
To: [email protected]
I always worry about establishing code formatting guides because in
my
experience it often devolves into unproductive arguments.
Scanning through the geronimo guides the only things I do not
particularly like are:
1. I prefer 2 spaces for indent to 4. It gives you more line length
for actual code to fix.
2. I prefer methods and classes to put the curly brace on a new line.
It helps me to identify where the method starts.
In my view the primary rule for any code formatting rules is that
they
be consistent within a file. So if a file uses 4 spaces for indent,
you use 4 (or you change it to 2 consistently in the file). I also
think you should only change the code formatting if you are a
significant contributor to the file.
I defiantly agree that tabs should be banned in any source file :)
Alasdair
On 16 February 2010 10:25, Jeremy Hughes <[email protected]> wrote:
On 16 February 2010 10:07, Guillaume Nodet <[email protected]> wrote:
I'd like aries to try using a single coding standards.
Specifically, i'd like us to agree on indentation rules (the code
uses
2 or 4 spaces in different places).
I'd like to propose the geronimo coding standards which is in use
in a
lot of projects at apache.
See http://geronimo.apache.org/coding-standards.html
I had a quick look. I agree to no tabs and prefer 2 spaces to 4. I
also think this needs to apply to xml.
Whatever the convention is, we should be able to codify it in an
Eclipse code formatter profile (and equivalents for other IDE). If
the
formatting convention requires manual steps to apply - i.e. anything
more than: select-all then ctrl-shift-f to format, then I don't
think
it will be applied consistently.
Btw, I really don't think we should enforce those at all cost using
maven plugins or such,
I didn't know there was one! This actually sounds like a perfectly
reasonable thing to do - like removing compile warnings, and
fixing or
filtering issues findbugs finds. So on the face of it I'm actually
+1
for this.
but agreeing on
those would allow to reformat the code once and not go back and
forth
between different standards.
+1 !!
Cheers,
Jeremy
--
Alasdair Nottingham
[email protected]
_________________________________________________________________
Tell us your greatest, weirdest and funniest Hotmail stories
http://clk.atdmt.com/UKM/go/195013117/direct/01/