[Dev] Coding Guidelines

[John Anderson]

I've always felt that

myMethod(argumentOne, argumentTwo, argumentThree)

was less readable than

myMethod (argumentOne, argumentTwo, argumentThree)

because we're used to reading prose with spaces between english words 
and "myMethod(argumentOne" doesn't seem like a word. Of course, the 
common practice is to write it without the space and I'm sure that 
because everyone prefers what they are used to, my preference would be 
in the minority -- and the majority opinion should win.

In the past there have been other standards which I personally find less 
readable, which have fallen out of practice, for example:

mymth(a1,a2,a3)

my_method(argument_one,argument_two,argument_three)

and

myMethod( argumentOne, argumentTwo, argumentThree )

all of which are less like the way you'd write prose.

John

Brian Kirsch wrote:

> Of course I vote for the non-space syntax method(arguments). I think 
> it is easier to read and more widely used.
> I do agree with Ted that we should standardize on one form or the other.
>
>
>
>
> Brian Kirsch - Email Framework Engineer
> Open Source Applications Foundation
> 543 Howard St. 5th Floor 
> San Francisco, CA 94105 
> (415) 946-3056 
>
> On Nov 18, 2004, at 2:33 PM, Ted Leung wrote:
>
>> See below.
>>
>>
>> On Nov 17, 2004, at 11:42 AM, John Anderson wrote:
>>
>>> The reason CPIA uses "sharedWebDAVCollections (self)" and services 
>>> uses "sharedWebDAVCollections(self)" is probably because I wrote 
>>> CPIA and Stuart wrote the services code. I use the extra space, most 
>>> other people don't. I prefer the space because I think it enhances 
>>> readabliity, especially when you get long strings of characters 
>>> without any spaces, e.g. 
>>> sharedWebDAVCollections(self,parameter1,parameter2,parameter3)
>>>
>>> In the past I've preferred strict coding standards which I thought 
>>> made the code more readable.  However as I've gotten older and more 
>>> comfortable with lots of different coding standards I'm less 
>>> bothered by small variations in style -- and, in an open source 
>>> world it's harder to enforce standards and in a commercial setting.
>>
>>
>> One factor for me is that having multiple styles makes it hard for 
>> some tools to work effectively on the codebase.   For example, it is 
>> much nastier to grep for both versions than only one of them.
>>
>> As far as the open source world goes, we determine who gets access to 
>> our repository.  If they refuse to follow our coding conventions, we 
>> don't have to let them in.  Part of being in a community is working 
>> within community norms.  The good open source projects admit new 
>> developers on the basis of merit, where merit is composed of a number 
>> of factors, and not only technical ones.
>>
>> Ted
>>
>>>
>>> So, although I have a presonal preference on this style issue I 
>>> think it's best to follow the group concensus.
>>>
>>> John
>>>
>>> Brian Kirsch wrote:
>>>
>>>> Hello,
>>>> I've noticed in the CPIA code that many of the methods declarations 
>>>> and calls have a space between the
>>>> method name and the argument list i.e.  def sharedWebDAVCollections 
>>>> (self). I was wondering if there was a specific reason for the 
>>>> space? The Services code uses the traditional methodName() syntax 
>>>> with no space. We should standardize on one form of the other to 
>>>> prevent a coding consistency problem among layers.
>>>>
>>>>
>>>> Brian Kirsch - Email Framework Engineer
>>>> Open Source Applications Foundation
>>>> 543 Howard St. 5th Floor San Francisco, CA 94105 (415) 946-3056
>>>>
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>> Open Source Applications Foundation "Dev" mailing list
>>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>
>> ----
>> Ted Leung                 Open Source Applications Foundation (OSAF)
>> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>>
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev