Python indentation (3 spaces)
Peter J. Holzer
hjp-python at hjp.at
Sat Oct 13 03:37:44 EDT 2018
On 2018-10-09 09:55:34 +0200, Antoon Pardon wrote:
> On 08-10-18 19:43, Peter J. Holzer wrote:
> > On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
> >> How wide my indents are on my screen shouldn't influence your screen
> >> or your choices.
> > Theoretically I would agree with you: Just use a single tab per
> > indentation level and let the user decide whether that's displayed as 2,
> > 3, 4, or 8 spaces or 57 pixels or whatever.
> >
> > 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?
Tabs are easy to catch. If a file contains a tab, reject it.
Spaces aren't, because spaces are everywhere. So you would have to check
whether a particular run of spaces should really be a tab, which is a
much harder problem. At the very least you will have to parse enough of
the language to find multi-line strings and indented blocks.
So it's easier to mandate "no tabs" than "only tabs for indentation".
Especially if you are dealing with more than one language. (I think
Python would be relatively easy. Perl is somewhere between hard and
impossible, but there is a library which can handle most
non-pathological code, C is somewhere between, etc. But the point is
that you would need a different checking tool for every language.)
hp
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | hjp at hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20181013/88663800/attachment.sig>
More information about the Python-list
mailing list