[Dev] Coding Guidelines

[Micah Dubinko]

This is just a bit of devil's advocate musing--feel free to ignore.

Though I have to say my views on coding guidelines have mellowed over 
the years.

Just like a city doesn't have a universal look and feel (though clumps 
of "planned communities" do), code doesn't always either. In fact, if 
you are navigating around an unfailiar city, differences in the 
neighborhood can be helpful, if even at a subconcious level, to figure 
out where you are and where you need to go. Same goes for a larger code 
base like Chandler.

I guess this falls under (3) below. Don't sweat the small stuff, because 
forcing it isn't worth the trouble. :)

.micah



Katie Capps Parlante wrote:

> Early in the project we made these decisions/agreements about coding 
> guidelines:
>
> (1) We would follow Python coding guidelines unless we had a 
> compelling reason not to.
>
> (2) In general, we would follow the coding guidelines of any project 
> we were working with. We recognized that this would lead to some 
> inconsistencies (wxPython/wxWidgets has different naming conventions 
> from Python, for example), and that it would be ok to be consistent by 
> module.
>
> (3) We wouldn't be super sticklers about all coding guidelines, only 
> ones we thought were particularly important. We recognized that folks 
> came from different projects with different habits, and decided that 
> as long as any particular module was consistent, that was good enough 
> for a bunch of formatting decisions.
>
> The gist of the decisions valued getting on with the project over 
> spending a lot of time arguing about coding conventions. :)
>
> I would have thought that the space-before-paren-after-method-name 
> issue would have fallen under #3, although I would concede the 
> argument that a consistent approach makes it easier to grep. At any 
> rate, if we decide its important to be consistent, then surely #1 
> would suggest we go with the no-space option.
>
> Cheers,
> Katie
>
>
> Ted Leung wrote:
>
>> And most other Python code is formatted this way.  +1 for paren 
>> immediately after the function name.
>>
>> Ted
>>
>> On Nov 19, 2004, at 9:37 AM, Bryan Stearns wrote:
>>
>>> Guido prefers the paren immediately following the function name:
>>> http://www.python.org/doc/essays/styleguide.html. (So do I, but I 
>>> think his
>>> +1 means more than mine in this case.)
>>>
>>> ...Bryan
>>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev



-- 
  Available for consulting. XForms, web forms, information overload.
  Micah Dubinko                           mailto:micah at dubinko.info
  Brain Attic, L.L.C.                        http://brainattic.info
  Yahoo IM: mdubinko
  Learn XForms today: http://xformsinstitute.com