Mailing-List: contact dev-help@creadur.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@creadur.apache.org
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPoyBqS0OXH9rnMS_CfP-T6UbrcEPBUov42ypX=aP4=kfNMHGg@mail.gmail.com>
References: 
 <CAPoyBqQFqFhtVGa4y5WOnb6+=hRdYH1Eq-wV8eT_1DOEGSc0pA@mail.gmail.com>
	<50673C4A.8010603@blueyonder.co.uk>
	<CAF8HOZJLX0rbujvoP9__qnhWywi1uLWsNxAWD3Z_XV=CY6KPWw@mail.gmail.com>
	<506740C7.6020701@blueyonder.co.uk>
	<CAPoyBqS0OXH9rnMS_CfP-T6UbrcEPBUov42ypX=aP4=kfNMHGg@mail.gmail.com>
Date: Sun, 30 Sep 2012 15:20:32 +0100
Message-ID: 
 <CAOGo0VZ8HyMbvozkbGW7iw2RUWUDfzC=CVHPqeFaYoKjhTPAAA@mail.gmail.com>
Subject: Re: Code Style [WAS Re: Various dev questions :-)]
From: sebb <sebbaz@gmail.com>
To: dev@creadur.apache.org
Content-Type: text/plain; charset=ISO-8859-1

The only rule I hope we can agree on is no TAB characters.
This because TAB settings are variable and can badly mess up indentation.

Consistency within a single source file is desirable for readability -
e.g. it's awkward to follow if indentation is not consistent.

But I don't see a particular advantage to consistency across all files
and file types.

For example, XML files often have deep nesting, so an indent of 2
chars is often better.
Whereas Java files don't (or should not) have deeply nested conditions
so 4 chars indentation is probably more readable.

IMO changing code to suit some arbitrary checkstyle rules is a waste
of time (and wasted effort reviewing changes).


On 29 September 2012 20:27, Olivier Lamy <olamy@apache.org> wrote:
> /me was just asking and don't want to start any holy war :-)
>
> 2012/9/29 Robert Burrell Donkin <robertburrelldonkin@blueyonder.co.uk>:
>> On 09/29/12 19:31, Jochen Wiedmann wrote:
>>>
>>> -1: I am just happy with different styles and don't see advantages in a
>>> common.
>>
>>
>> Fine by me
>>
>> Robert
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy