Mailing-List: contact pig-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pig-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Wed, 07 Nov 2007 09:52:10 -0800
Subject: Re: question on coding style and testing
From: Ted Dunning <tdunning@veoh.com>
To: <pig-dev@incubator.apache.org>
CC: Nigel Daley <ndaley@yahoo-inc.com>
Message-ID: <C3573B4A.27A21%tdunning@veoh.com>
Thread-Topic: question on coding style and testing
Thread-Index: AcghZutpKkDut41aEdymZgAWy8rVfQ==
In-Reply-To: <B448C3DF-678E-46C4-945C-11EA46E5E1EA@yahoo-inc.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit


Actually, tabs really do increase the probability of screwing up
indentation.  The problem is that they don't have a universal meaning
(actually, they do, but lots of people ignore it).  That means that people
will build indentation with mixed tabs and spaces and get different results.

The good news is that leading spaces still have a universal meaning (1
space).

I would like people to use whichever option results in less discussion.  If
that means forbidding tabs that is fine with me (my IDE handles that without
any problems).


On 11/6/07 3:08 PM, "Utkarsh Srivastava" <utkarsh@yahoo-inc.com> wrote:

> What's wrong with tabs? I hate spaces. With tabs there is less
> probability of having messed up indentation.
> 
> Utkarsh
> 
> 
> On Nov 6, 2007, at 3:03 PM, Benjamin Reed wrote:
> 
>> Definitely no mixing tabs and spaces. We should not use tabs!
>> 
>> ben
>> 
>> On Tuesday 06 November 2007, Nigel Daley wrote:
>>> +1 to Alan's comments on NOT mixing tabs and spaces.  FWIW, we can
>>> enforce this with the Checkstyle tool once the current code base is
>>> fixed to follow the convention.
>>> 
>>> Nige
>>> 
>>> On Nov 6, 2007, at 12:11 PM, Alan Gates wrote:
>>>> I'm mostly fine with the sun conventions.  You suggested staying
>>>> with an indentation of 4.  The sun conventions say tabs must always
>>>> be set at 8.  I strongly dislike mixing tabs and spaces, as it
>>>> tends to make a mess out of code.  I don't care if we agree to do
>>>> our indents as one tab (and then let people set their tabs as they
>>>> see fit) or to only uses spaces.  But I'd like to not mix the two.
>>>> 
>>>> Alan.
>>>> 
>>>> Benjamin Reed wrote:
>>>>> My vote would be Sun's conventions. Hadoop uses Sun's conventions
>>>>> except for two spaces per level. It would be much better IMO to
>>>>> stick to straight Sun conventions.
>>>>> 
>>>>> ben
>>>>> 
>>>>> On Monday 05 November 2007 12:21:31 Olga Natkovich wrote:
>>>>>> Hi Antonio,
>>>>>> 
>>>>>> My understanding is that each project develops its own style and
>>>>>> that's
>>>>>> part of the incubation process. One general rule that I think we
>>>>>> should
>>>>>> be using is that if you making changes in an existent file you
>>>>>> adhere to
>>>>>> the style of that file to preserve readability of the code. I was
>>>>>> thinking that we should be looking at the rules that hadoop is
>>>>>> using as
>>>>>> the starting point to decide what works for us and what requires
>>>>>> changes:
>>>>>> 
>>>>>> http://wiki.apache.org/lucene-hadoop/
>>>>>> 
>>>>>> Look at the Developer Documentation section.
>>>>>> 
>>>>>> Olga
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Antonio Magnaghi [mailto:antmagna@yahoo-inc.com]
>>>>>> Sent: Monday, November 05, 2007 12:15 PM
>>>>>> To: pig-dev@incubator.apache.org
>>>>>> Subject: question on coding style and testing
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I have a couple of related questions about coding style/
>>>>>> guidelines and
>>>>>> unit tests.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I have researched the few pages on the Apache website and was not
>>>>>> able
>>>>>> to find what I am looking for.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I am curious about policies that may be in place, as I am new to
>>>>>> Apache.
>>>>>> I am wondering if there are policies in terms of coding styles
>>>>>> like
>>>>>> naming conventions for variables, unit tests requirements,
>>>>>> possible code
>>>>>> coverage requirements (or other types of validation on check-ins
>>>>>> other
>>>>>> than peer-review).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Are there general guidelines? Or maybe each single project has
>>>>>> some
>>>>>> degree of freedom in setting up its own?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> -a.
>> 
>> 
>