[geos-devel] TABS or SPACES - ALL DEVELOPERS and PSC Vote

[Howard Butler]

On 9/11/18 6:44 AM, Sandro Santilli wrote:
> On Mon, Sep 10, 2018 at 01:15:25PM -0700, Paul Ramsey wrote:
>> Same. 2-spaces hurts my little brain.
> I'm happy as long as you give me a recipe to make my editor
> (vim) automatically use what we choose AND `make check`
> ensures any future change stick with what was choosen.
>
> Note I'd like to keep the 80 cols limit on line width which
> with current naming can easily become close-to-impossible
> with too many spaces. This also means if we use tabs we want
> them to be rendered by a determined number of spaces, or it
> would be impossible to determine the 80 cols limit ...
>
> Go Vicky go !

I don't edit GEOS much these days, but I would caution that the
strictness in the formatting area further discourages contribution and
makes it so only insiders feel comfortable contributing. "A company
style" is a great thing when working on private projects. I fully
appreciate it, but I think that it's really difficult to do it in an
open source setting unless the gatekeepers are really diligent (Linux
kernel, etc) and the automated tools do much of the work instead of
throwing the style violations back in the face of contributors.

Those automated tools are going to create churn in the history no matter
what, and you're going to have a huge changeset where everything adjusts
to the new regime that prevents conveniently looking back in the history
previous to that. What problem does forcing developers to declare their
intention in this religious war actually solve for GEOS?

I think that GEOS' style is already quite consistent and doesn't need
editor enforcement and process around it. I mean, we already know it
looks, feels, and acts just like Java :P

Howard



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20180911/913ee0fa/attachment.sig>