indent

Josh Sled jsled at asynchronous.org
Wed Mar 14 17:23:47 EDT 2007


On Sat, 2007-03-10 at 14:57 +0100, Christian Stimming wrote:
> (If I speak for myself, I rather prefer -bl -bli0 i.e. the braces after if on 
> a new line, but I know this style is used only by a minority and in this case 
> I think the benefit of a uniform style outweighs by far the discomfort of not 
> seeing my individual preferences applied.) 

Agreed.  I certainly prefer the '-bl -bli0' style, but it's far more
important that we're consistent.


> So: When will the One Great Indentation Commit happen in SVN, who will do it, 
> and how do we enforce this style for future commits? 

The timing argument is similar to the Great Renaming we've discussed ...
probably best immediately before a public pre-release series, such as
the upcoming 2.1.0.  At that point, any outstanding changes are
minimized, and we're at a point where we won't need to back-port fixes
to a previous release line with a different style.

Part of the motivation for doing the Great Renaming at that point is to
minimize the amount of "public" stack traces from testing of builds that
are contain the "old" names.  That argument doesn't really apply here.

The bigger issue is the other major "pending" changes right now: the
gobject-dev, gda-dev and modules-cleanup branches.  I suppose each of
them could be separately "ident-ified", and then any cross-merging that
needed to occur could simply skip the reformatting changeset.  Of
course, they'd all want to merge up to the revision of pre-reformatted
trunk before being re-formatted themselves.  A bit messy, but I don't
think it's horrible with communication.

I think David should do the reformatting.


I'd imagine editor configuration is the primary way the formatting will
occur; I've not yet come up with the proper emacs incantations for the
style.  Perhaps a 'gnucash-c-mode' for convenience.  We could add emacs-
or vi-style mode lines to individual files as well, but if devs already
have their editor configured, that becomes redundant.  HACKING should be
updated to include the details.

Social mechanisms are probably the best enforcement.  I don't think we
want to automate running indent on every commit or anything.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070314/9cad6f71/attachment.bin 


More information about the gnucash-devel mailing list