[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