Indentation

[rdtechie]

I've been reading into the Linux Kernel documentation lately, and I've noticed that all their code uses a 8 characters for indentation. Source here: https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst

At first I was skeptical, but the more I was reading through the Linux kernel source code, the more it became clear to me that that level of indentation makes it really easy to read. While 4 characters is indeed already a good level of indentation, I think that 8 characters makes code even more easier to read.

Hence the question, why for PowerShell code we use 4 characters?

Personally, I don't find the reason of "this is the default for PowerShell ISE" relevant, because also in the Linux kernel source code they don't say "hey, we use EMACS so let's adjust our code style to the default settings of EMACS". Code style should be independent of what editors people are using.

[Jaykul]

First, Linus uses TABS not 8 characters. (See my comment on #81)

Second, Linus is WRONG. The kernel coding style guide you are referring to is an outlier ... Look at C, C++, BSD, GNU, Linux kernel, Google's JavaGuide and the dotnet and asp.net style guides. They all use 4 spaces, except the Linux Kernel, which uses TABS, and Google's Java guide and the GNU guide, which use 2 spaces.

I always like to point out that his style guide proves that none of the supposed benefits of tabs materialize in real life: in addition to requiring tabs, Linus has to dictate to you the configuration of your text editor (you must set your editor to render tabs as 8 characters) because he wants to require an 80-character line limit, and he wants to count tabs as 8 characters.

We disagree with his style guide on many points (maybe as many as we agree with).

• You will use more than 3 levels of indenting, PowerShell pipeline functions start 2 levels deep.
• You should not squash your case statements to the same level as your switch: if there's a brace, you should indent.
• You should never leave off braces from conditional statements
• You must use mixed case variable names, not snake_style_connected_words
  ...

Oh, and another thing ... that line about "ISO/ANSI screen size is 80x24" is so dated, that I bet nobody under 34 will even understand it.

Do you know why people use 80 columns as the standard width?

It's because that's how many columns there were on an IBM punch card.

Do you know why terminals have only 24 lines?

Hint: punch cards had 12 😠
Nope, that's not why: screens in the early days were all built with standard television cathode ray tubes, which had a 4:3 aspect ratio, and you may remember the vt100?

[kilasuit]

Owch i just read the linux guidelines linked above and I can safely say I'm Not a Fan

[michaeltlombardi]

FWIW, I hate the 4-space indent (strongly prefer 2-space indents), but I grok that I lost that hill a long time ago. Luckily, my editor has different settings for different languages.

[Jaykul]

Yeah, I have to say that before I got involved in "best practices" and trying to set "community standards" ... I used to use 3 spaces 😳

I bet that if we were willing to stipulate that "in source control, all indents are in multiples of 4 spaces" we could write a git extension to adjust it to whatever you like (I mean, I know my editor can do that anyway, but it would be something I'd actually use if it was automatic in/out).

[rdtechie]

Thanks Joel for the reply. After thinking over your reply, and taking into consideration what Linus dictates, I come to a conclusion. This conclusion is consistency. I think it's also stated somewhere in the C programming book of K&R. It doesn't matter what style you choose, as long as you're consistent.

And personally I've always used 4 spaces as indentation level and I love it. Two spaces tend to be less readable to me. Sorry @michaeltlombardi ;)

[Jaykul]

That's very much true, @rdtechie -- in fact, the only reason for a community style guide is to try and encourage consistency across the community. That is, we never set out to dictate how you should write PowerShell, but more to document the majority opinions.

We've even deliberately left things out in cases where there's not a clear community preference 😉