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

Bengt Kleberg <>
Thu Feb 6 09:50:56 CET 2014


Greetings,

These are my opinions, not fact.

It is unfortunate that formatting before check in it is not a viable
way. To be honest I do not follow your reasons, but I accept them.
I thought that since it is used in Go it would be possible for other
languages as well.


bengt

On Thu, 2014-02-06 at 09:38 +0100, Loïc Hoguin wrote:
> 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
> > 
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> 



More information about the erlang-questions mailing list