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

Bengt Kleberg bengt.kleberg@REDACTED
Thu Feb 6 10:21:25 CET 2014


Greetings,

These are my opinions, not facts.

We have erl_tidy:file/2 that ought to be a good starting point to mimic
gofmt.


bengt

On Thu, 2014-02-06 at 10:10 +0100, Ali Sabil wrote:
> 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
>         
> 
> 




More information about the erlang-questions mailing list