db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: Official stance on tabs
Date Wed, 23 Mar 2011 00:50:49 GMT
> That does help. Personally I would like some convention but since plenty of the legacy
code doesn't really follow this standard,
> I think I'll be lenient when committing other people's code; especially when it comes
to GSoC. Deadlines are usually tight and
> it's probably best not to lose time with cosmetic back and forth of patches.

I think this is a good discussion.

For my part, I think the most important thing is:

	fit in with the existing code

When I am working on/with a patch, the patch is usually
a small change to one area of a file, so I generally try
to make the indentation of my patch fit nicely with
the surrounding code. If that file uses hard tabs, I
use hard tabs; if it uses spaces, I use spaces; if it's
already a mix, I just do the best I can to fit in cleanly.

When it comes to committing a contributed patch, I will
often fix up the indentation myself, at the very end,
after all the substantive issues with the patch have
been dealt with. I've noticed that other Derby committers
have done this as well, without any downside that I've noticed.

I also agree that churning through multiple patch revisions
just to tinker with the whitespace isn't very productive.
My observation is that most regular Derby contributors are
sensitive to this already, and generally contribute patches
with few or no unnecessary whitespace diffs, so as a
community we seem to have evolved a practice that works
well enough for now.

Thanks for airing your concerns, and I hope these ideas help!


View raw message