[hermitdev]

Personally, I prefer hard tabs to spaces. The rationale is simple: every single dev I've worked with has had a separate preference on how many spaces ahould be used for an indent. I've seen 2, 3 and 4 commonly used. If you use hard tabs, every dev can set their editor to their indentation of choice. If you use spaces, that freedom is lost.

I say this as a currently predominantly Python dev, where spaces are encouraged and recommended, but I disagree as stated above.

Currently, I prefer a 2 space indent after previously using a 4 space indent for decades.

[tetha]

In my book, the answer has always been: tabs for indentation, spaces for alignment. Tabs allow everyone to choose the gap for new blocks they like, and spaces make sure that a gap of 16 characters is always a gap of 16 characters (because whatever you align with is 16 characters long).

Practically, I eventually got fed up explaining this. Spaces only is easier to explain, because there is very little to get wrong with "spaces only".

[eterm]

Python 3 won't compile with mixed indentation so by recommending a mixture you're picking a fight you cannot win and still have python programmers along with you.

[JackC]

Seems like it will to me. Here's an example using tabs for indent and spaces for alignment:

https://repl.it/repls/SubduedLegalDisk

[eterm]

I can't follow that link but I'll trust you, I was just going off what the documentation had to say: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

My reading of "Disallow" must be wrong.

[dkersten]

As long as you always “indent” with tabs and only use spaces after, you’re good, I believe. That is, if you want to align something, you just first indent to the level of the previous line with tabs and then you can use spaces for alignment within that indentation level. What you can’t do is, for example, have a space and then a tab.

[hn_throwaway_99]

My argument against this is that I have never, ever seen a tabbed code base where if you changed the original tab size of the author the code didn't end up looking like total shit, usually because of next-line alignment issues.

IIRC the original Sun Java source used an 8-space tab width, and looking at it with a 4-space width made it much more difficult to read.

[pvinis]

I don't know why I can't downvote you so I need to reply.

This probably happens because there are tabs used for alignment too. Like many many many people have said, tabs are for indentation, spaces are for alignment. When people advocate for tabs, they understand their meaning, and they also use spaces for alignment. If someone uses tabs for everything always forever everywhere, they might as well just use only spaces.

[dTal]

>I don't know why I can't downvote you so I need to reply.

Because you can't downvote posts more than 24 hours old.

I'm not sure why you'd want to downvote that post anyway; it made a reasonable point in a polite way. Replying is better than downvoting unless the original post made an egregious sin.

[pvinis]

I consider a downvote as a disagreement with no further comment. But I understand what you're saying.

[kazinator]

> If you use spaces, that freedom is lost.

The lost freedom can be found again: hack an open source editor to render leading spaces as elements that have a configurable width.

Nobody who calls themselves a programmer should be whining about this, really.

[dkersten]

This only works in some editors while tab width works in almost every text editor ever. Also, when the visually impaired people from the post complain that it really is a problem for them, that’s hardly whining — that’s you ignoring their (very valid, IMHO) struggles and concerns.

[cafard]

I do 99% or more of my Python programming in emacs, where in python-mode a tab automatically turns into spaces.

[wahern]

> If you use spaces, that freedom is lost.

That freedom isn't lost. As the pro-space camp is wont to point out, you're free to pile on another layer of translation software to revert the translation software that transformed the original tab input to a set of spaces.

And because everybody is using programmable IDEs (or IDEs that have had all possible programs precompiled into them), this translation will be part of your 10MB init config file, and because it's 2019 the translation is guaranteed to work with 100% fidelity. It's seamless!

Also, Google uses spaces, and if it's good enough for them, end of story. No matter that KNF (kernel normal form) for Linux, Solaris, and all the BSDs uses hard tabs, not to mention countless GNU projects. Unix developers aren't accustomed to writing readable, shareable source code that interoperates with a diverse set of tooling.

[hermitdev]

Freedom is lost. I'm unaware of any IDE that will expand a 2 space indent to 4 on commit, without using special hooks.

Google using spaces means jack didly squat to me. I dont work for them and never will. Frankly, I disagree with a lot of their published coding styles for Python and C++. It may work for them, and I understand why they may want that homogony internally, but doesn't mean I have to like or use their style.

Don't want to start a holy war, but just my perspective.

[rendall]

"Also, Google uses spaces, and if it's good enough for them, end of story"

That's no argument

EDIT: The commenter is being sarcastic. Don't downvote them :)

[RoddaWallPro]

"10MB init config file" - this is the point at which you gotta realize they are being sarcastic.

[rendall]

I think you're right. I read it quickly on mobile and missed that.

[wahern]

A commenter in that Reddit thread made that argument, more or less: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

[cmroanirgo]

> Google uses spaces

Btw, Bill Gates uses tabs[0], so any decisive argument is impossible these days, because of legoog.

Personally, I prefer to make up my own mind on what I use rather than relying on big/ ¿evil corps design practices. I'm with GP and BG on this one though.

[0] https://www.businessinsider.com.au/bill-gates-on-tabs-versus...

[sundvor]

Your sarcasm is brilliant; top points! :-)

All tabs for me. We can configure your editors to show it as whatever we want; no post and pre check in transformation needed. Accessibility is another reason. So really, why is this even an argument?

[kazinator]

Doesn't work for blocks that contain nested indentation levels, but are themselves positioned from something aligned:

   (long-function-name (lambda (arg ...)
                         (let ()
                           (...)))
                       more args ...)

That (lambda ...) doesn't start on a tab-established indentation; it's an argument to long-function-call. But inside the (let ...), it's indentation as usual. If we rename long-function-name, to something that is one character longer, the whole lambda block moves one character to the right.

If you think this is just Lisp, think again; thanks to its influence, such patterns are showing up all over the place in numerous languages.

[wahern]

But that style elides the distinction between syntax and semantics by making indentation a function of the number of letters in an identifier. The above code isn't indenting so much as typesetting--aligning visual elements, not grouping semantic components such as compound statements. If you're typesetting and the only thing you can rely on is monospace fonts, then of course you must use spaces. That's reflected in the rule, "tabs for indentation, spaces for alignment."[1]

The lack of convenient semantic cues in the source file representation is exactly what burdens the visually impaired disproportionately. The well-sighted don't need a specialized parser and formatter for a language as a prerequisite to reasonably comfortably reading and editing because visual alignment suffices. The history of teletypes and keyboards made tabbed indentation an accidental equalizer when it came to source code editing. The well-sighted needed to willfully change convention to discard that benefit, and did so for highly dubious reasons.

[1] Which arose out of the tabs v spaces debate as a principled compromise and is not itself a historical style, AFAIK.