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

Ali Sabil ali.sabil@REDACTED
Thu Feb 6 10:10:18 CET 2014


A first step would be to have something like gofmt for Erlang.


On Thu, Feb 6, 2014 at 9:50 AM, Bengt Kleberg <bengt.kleberg@REDACTED>wrote:

> 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
> > > erlang-questions@REDACTED
> > > http://erlang.org/mailman/listinfo/erlang-questions
> > >
> >
>
> _______________________________________________
> 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/20140206/7bc2ea89/attachment.htm>


More information about the erlang-questions mailing list