On 2018-10-16 06:37:56 +1100, Chris Angelico wrote:
> On Tue, Oct 16, 2018 at 6:34 AM Peter J. Holzer <hjp-pyt...@hjp.at> wrote:
> > On 2018-10-15 14:12:54 +0200, Antoon Pardon wrote:
> > > On 13-10-18 09:37, Peter J. Holzer wrote:
> > > > On 2018-10-09 09:55:34 +0200, Antoon Pardon wrote:
> > > >> On 08-10-18 19:43, Peter J. Holzer wrote:
> > > >>> In practice it doesn't work in my experience. There is always someone
> > > >>> in
> > > >>> a team who was "just testing that new editor" and replaced all tabs
> > > >>> with spaces (or vice versa) or - worse - just some of them.
> > > >> Isn't that caugth in the process of commiting to version control?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Underlined to emphasize the context.
> > > > Tabs are easy to catch. If a file contains a tab, reject it.
> > > >
> > > > Spaces aren't, because spaces are everywhere.
> > >
> > > Spaces that replaced a tab by accident, are easy to catch too. They are
> > > all
> > > those lines that show up when you do a diff with the previous version that
> > > shouldn't show up.
> >
> > And where is the AI that decides which lines in a diff are should show
> > up?
> >
> > Whether a line in a diff should or should not show up seems to me to be
> > even harder to determine than whether a tab fits the syntax.
> >
>
> If there's a change, it shows up. If there's no change, it doesn't show up.
>
> Ergo, if you accidentally replace a tab with spaces, it's a change,
> and it shows up.
If any change "shows up" (i.e., is rejected by the pre-commit hook of
your version control system) you can't change anything which makes using
a version control system rather pointless.
So you still need to distinguish between "intended changes" and
"unintended changes". Simply rejecting changes which only affect
leading whitespace won't work either since you may have accidentatlly
changed the leading whitespace while intentionally changing something
else in the line (false negative) or you may have intentionally changed
leading whitespace to correct and earlier indentation error which wasn't
caught (false positive). So that still looks like a non-trivial problem
to me which is better solved by humans during code review than by some
commit-hook.
hp
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | h...@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
