[erlang-questions] Controversial subject of the day: tabs and spaces for indentation
Thu Feb 6 09:38:10 CET 2014
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
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:
> 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.
> 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
>>> 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
More information about the erlang-questions