[erlang-questions] Controversial subject of the day: tabs and spaces for indentation

[kraythe .]

Actually the solution to this age old debate was proposed to me by a friend
of mine and its genius on a number of levels but isn't implemented
anywhere.  The reality is that for most languages whitespace is irrelevant
so it shouldn't be the code holding the indentation but the user's
preference file. Imagine a source code repository where there is NO
irrelevant whitespace in the code base. For java, for example, there would
be literally only one single line of code. Now when you check out you have
a preference file that says you want tabs or spaces or mixed and also
defines the other formatting you prefer. When you check out the system
reformats the code according to your specs dynamically. When you commit, it
strips your code of whitespace before comparing.

Now that would rock. Not just for tabs but the other code holy wars like
drop braces and so onl

*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*


On Wed, Feb 5, 2014 at 2:21 PM, kraythe . <kraythe@REDACTED> wrote:

> Actually the solution to this age old debate was proposed to me by a
> friend of mine and its genius on a number of levels but isn't implemented
> anywhere.  The reality is that for most languages whitespace is irrelevant
> so it shouldn't be the code holding the indentation but the user's
> preference file. Imagine a source code repository where there is NO
> irrelevant whitespace in the code base. For java, for example, there would
> be literally only one single line of code. Now when you check out you have
> a preference file that says you want tabs or spaces or mixed and also
> defines the other formatting you prefer. When you check out the system
> reformats the code according to your specs dynamically. When you commit, it
> strips your code of whitespace before comparing.
>
> Now that would rock. Not just for tabs but the other code holy wars like
> drop braces and so onl
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
> On Wed, Feb 5, 2014 at 1:33 PM, Vlad Dumitrescu <vladdu55@REDACTED>wrote:
>
>> On Wed, Feb 5, 2014 at 8:27 PM, Garrett Smith <g@REDACTED> wrote:
>> > On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu <vladdu55@REDACTED>
>> wrote:
>> >> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith <g@REDACTED> wrote:
>> >>> It seems to me that this problem is easily solved by inverting the
>> interests:
>> >>> - Fix erlang-mode to default to all spaces
>> >>> - OTP team includes the appropriate Emacs code headers in the source
>> >>> files (or the dot file in the source root directory as Magnus just
>> >>> pointed out) and leave them horribly formatted, per their preference
>> >>>
>> >>> Does this not trivially solve the world's Erlang indent problems?
>> >>
>> >> Unfortunately, no. If I make a patch without emacs, my editor will
>> >> still use something else than a mix of tabs and spaces, so it will
>> >> have to be OTP-ified by hand (copying indentation from other lines) or
>> >> by running it through emacs just for that.
>> >>
>> >> Which, in a funny turn of events, brings me to a question related to
>> >> the previous "holy war": can emacs open, reindent and save files in
>> >> bach mode? That would indeed help! (even if one would still have to
>> >> install emacs).
>> >
>> > This seems like a problem that can be confined to the OTP team and
>> > process, which is I think is a pretty small subset of all erlang-mode
>> > users, no? And changing erlang-mode to default to spaces doesn't make
>> > this worse does it?
>>
>> You are right, it's better like you suggested and definitely a step in
>> the right direction. But I think that most Erlang projects are more
>> lenient regarding whitespace mismatches in patches (being much
>> smaller) and thus the project where it hurts the most to be
>> non-compliant is not going to be affected. Yet.
>>
>> /Vlad
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140205/3567ab4a/attachment.htm>