[Dev] Coding Guidelines

[Ted Leung]

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