On Sat, Mar 16, 2013 at 1:09 AM, Phil Harvey <p...@philharveyonline.com>wrote:

> I'm feeling a bit guilty about this one because I suspect it was my
> indentation-related review comments on some of Ken's recent soak test work
> that may have been the catalyst for this thread.
> We've got a few options about what to do, each bringing their own special
> kind of pain.
> I would be in favour of converting existing Proton Python files to use 4
> spaces.  This obviously entails the up-front pain of doing the conversion,
> plus some mild, occasional pain when diff-ing a file's version history that
> spans the re-indentation commit (you can ignore whitespace using "git diff
> --ignore-all-space" or "svn diff -x --ignore-space-change").

On what basis do you consider this pain mild and occasional? Have you ever
tried diffing a python file (or any other white space sensitive format)
with either of those options you just suggested? I can see that it might be
mild pain for you because you would just read the source code as it exists
today. For the original author/maintainer of the source code it is rather
more important to see how and why the original intention of the design/code
has been changed over time.

> I think this is preferable to the frequent, long-lasting pain of switching
> between 2-space and 4-space indentation when I navigate across files within
> the project.  Not to mention the occasional, *severe* pain of debating
> indentation styles on the mailing list.  Surely no one is actually enjoying
> this discussion, and if we don't resolve it now then it's sure to come up
> again in six months time ;-)

FWIW, my editor automatically detects the indentation level being used in
the file and adapts accordingly. It might be worth seeing if a similar
option exists for yours. There are also a lot of good folding editors out
there and/or editors that will automatically highlight the current block
for you, so in terms of ease of maintenance and readability, I suspect
there is a lot that can be done to control your experience without having
to update all the source code in the repo to follow your favourite format.

> My second choice would be that we make all the Proton Python files use
> 2-space indentation.  Despite my preference, ceteris paribus, for 4 spaces,
> this would be a less disruptive change based on Rafi's statistics.
I think to some degree it is difficult to avoid having *some* level of
heterogenous formatting standards in a code base like Proton. For example
for windows support we've pulled in a BSD licensed getopt implementation
that happens to use tabs rather than spaces, and it would obviously be a
bad idea to convert it just to meet our defacto C coding standards. I've
also been tempted to pull in a public domain hashtable and regex
implementation and again, given that I don't plan on taking over
maintenance of those items, updating them to match the rest of the code
would just make it more difficult to apply patches. Even on the Java side
the stuff under contrib uses different coding conventions from everything

To be clear, I'm certainly not saying we shouldn't strive for consistency
within our own work, but the simple reality of the open source world is
those who do the work get to decide how to do it, especially on small
things like formatting, and for a project like Proton we want as many other
people doing work as possible. I'm certainly not going to turn down any
volunteers to maintain the php bindings because they want to use a
different indentation than I might have used.

Given the above, I think between contrib, integration, binding, and/or
external code, there are likely going to be parts of the proton repo we
can't/shouldn't try to apply our standards to, so we need to be clear on
what components of proton we're attempting to specify here, and of course
as always there is lasting benefit to knowing how to make your editor deal
gracefully with alternative formatting, particularly given that it would be
impractical to change the 40-50K lines of python code in the rest of qpid.


Reply via email to