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

[Loïc Hoguin]

You can't reasonably do it when merging. You would have to amend each 
commit individually with the whitespace fixes. Then you would have to 
test again, because your whitespace program may have broken your own 
program.

Plus this doesn't help your code get merged at all. If you submit code 
with broken whitespace, then tools will also display this whitespace 
change. You can of course hide whitespace changes, but the problem is 
that whitespace does matter in some places, so you're basically hiding 
potentially important information by doing that.

I also highly doubt that "the owner would be able to accept more code". 
Like I said before, this is a minor annoyance at best.

He wouldn't appear nicer either, because he has to spend extra time on 
each PR, meaning they get merged slower, which is a bigger annoyance 
than telling people to fix the whitespace they broke.

The contributor can quickly see if they broke whitespace after 
submitting the PR on github by looking at the diff tab. I'm always 
surprised when people submit a PR with obviously broken whitespace and 
do nothing about it until I point it out.

Contributors aren't the ones who are going to maintain the code. They 
just write and forget. Therefore they should be the ones who make sure 
that what they submit is well-formed so as to not become an 
inconvenience to the project owner, who is going to maintain their code 
for them for free.

On 02/06/2014 08:30 AM, Bengt Kleberg wrote:
> Greetings,
>
> These are opinions, not facts.
>
> It is correct that the project owner has decides what goes into the
> project. Why would it be a bad idea for this owner to automatically
> format every thing that is checked in?
>
> On the plus side (s)he would be able to accept more code this way and
> appear nicer to would be contributers.
>
>
> bengt
>
> On Wed, 2014-02-05 at 22:18 +0100, Loïc Hoguin wrote:
>> On 02/05/2014 09:48 PM, Raoul Duke wrote:
>>>> One line? That's the worst solution ever. You break every tool ever, and
>>>> even make *cat* and *less* useless (pun intended).
>>>> Code is text, so keep it readable without requiring any special crappy
>>>> editor.
>>>
>>> yes and no. these are the problems and solutions we have to trade off.
>>> what is the lesser evil in the long run? probably people disagree.
>>
>> ???
>>
>> There is no evil, this is at most a minor annoyance that comes with
>> pointless debates shrouded by blind religious beliefs.
>>
>> The answer is always "submit code the way the project owner wants you
>> to" and no amount of debating is going to change that, ever.
>>
>> It's not even just tabs vs spaces, plenty other minor things are the
>> author's choice, including number of columns, newline characters, source
>> code encoding, but also major things like mandatory documentation or
>> tests and backward compatibility.
>>
>> There is no one true way of doing things, for this or for anything else.
>> It's just a matter of choice.
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

-- 
Loïc Hoguin
http://ninenines.eu