Re:Black, the uncompromising Python code formatter, is stable
by dmurray on Saturday January 29, 2022 @10:28PM
(#30133636)
Since Black enforces that indents are exactly four spaces, you could configure your editor to render four spaces at the start of a line as two spaces, getting exactly the behaviour you desire from tabs.
An editor plugin for this wouldn't even have to be syntax-aware, except for some rare cases where you are using spaces to nicely align a multiline string.
Re:Black, the uncompromising Python code formatter, is stable
by afavour on Sunday January 30, 2022 @01:40AM
(#30134665)
“Since black enforces four spaces, all you need to do is reinvent the functionality of tabs”
I know it’s very far from the biggest problem in the world but this does make me chuckle a little.
Re:Black, the uncompromising Python code formatter, is stable
by GeorgeTirebiter on Saturday February 05, 2022 @04:40PM
(#30226420)
The proper number of spaces seems to me to be dependent upon the font size. Smaller font, more spaces.
In the olden days, with fixed width fonts on an 80x24 terminal, I think I read somewhere that 3 spaces was optimal (fewest bugs); but that programmers have an aversion to non-multiples of 2. That is why you see 2- or 4-spaces, but not 3. (I think...)
My personal preference is tabs for indentation, spaces for alignment. The reason for this is the customizability that comes with tabs instead of spaces. Any editor worth using for coding has an easily configurable tab stop that you can set to your desired space count. With tabs and proper editor configs, everyone can be happy with how their code looks while remaining absolutely identical with no tools reformatting on checkout or commit (as I've sometimes seen).
For a long time, I was in the 4-space indentation camp. These days, I prefer 2. The reality is, though, I use whatever the codebase I'm working on has as "standard".