[Swift-devel] Code style

[Tim Armstrong]

 I knew this was going to end badly as soon as I saw the initial email.

2 spaces, no tabs, } else {, 80 characters wide.  Discuss.

The only helpful comment I have with the discussion is that it's a real
pain to maintain patch-sets (or a code branch) against code with
inconsistent indentation or formatting, since you can't fix any of it
without ruining your ability to merge changes.  This doesn't seem to be a
major problem for Swift.

- Tim


On Tue, May 14, 2013 at 10:28 PM, Ben Clifford <benc at hawaga.org.uk> wrote:

>
> oh i can argue this all night.
>
> > > If someone wrote some code with tab = 4, and committed it, and someone
> > > else wrote code with tab = 8, maybe even in the same file, there is no
> > > consistent value to use.
> >
> > A tab is a tab. You can't write a file with both 8 space tabs and 4
> > space tabs. You can however write a file with 8 space indentations vs. 4
> > space indentations if you don't use tabs exclusively.
>
> Person A commits some code with a single tab indent.
> Person B has their display set to tab = 8 and adds new lines with 8 spaces
> rather than using the existing indentation byte sequence.
> Person C has their display set to tab = 4 and adds new lines elsewhere in
> the file with 4 spaces, rather than using the existing indentation byte
> sequence.
>
> Now you have a file with both 8 space tabs and 4 space tabs.
>
> it seems hardest of all to stop people using their own favourite
> indentation sequence rather than the pattern already used. (make tabs and
> spaces have different colours and a bunch of the communally edited code I
> work with looks pretty puke)
>
> --
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20130514/9984d912/attachment.html>