Microsoft Veteran Ditches Team Tabs, Blaming Storage Trauma of Yesteryear (theregister.com) 125
Veteran Microsoft engineer Larry Osterman is the latest to throw his hat into the "tabs versus spaces" ring. From a report: The debate has vexed engineers for decades -- is it best to indent code with tabs or spaces? Osterman, a four-decade veteran of Microsoft, was Team Tabs when storage was tight, but has since become Team Spaces with the advent of terabytes of relatively inexpensive storage. "Here's the thing," he said. "When you've got 512 kilobytes, and you're writing a program in Pascal with lots of indentation, if you're taking eight bytes for every one of those indentations, for eight spaces, you could save seven bytes in your program by using a tab character."
It all added up, even when floppy disks were part of the equation.
However, according to Osterman, things have changed. Storage is less of an issue, so why not use spaces? A cynic might wonder if that sort of attitude has led to the bloatware of today, where software requires ever-increasing amounts of storage in return for precious little extra functionality and a never-ending stream of patches. Any decent compiler should strip out any extraneous characters, assuming the code is indeed being compiled beforehand and not interpreted at run-time. For his part, Osterman is now a member of team spaces. "I like spaces simply because it always works and it's always consistent," he said.
It all added up, even when floppy disks were part of the equation.
However, according to Osterman, things have changed. Storage is less of an issue, so why not use spaces? A cynic might wonder if that sort of attitude has led to the bloatware of today, where software requires ever-increasing amounts of storage in return for precious little extra functionality and a never-ending stream of patches. Any decent compiler should strip out any extraneous characters, assuming the code is indeed being compiled beforehand and not interpreted at run-time. For his part, Osterman is now a member of team spaces. "I like spaces simply because it always works and it's always consistent," he said.
oh, this'll be fun... (Score:5, Funny)
Get your POPCORN here!
really, a spaces vs tabs flamewar in 2024?!
Re:oh, this'll be fun... (Score:5, Funny)
Re: (Score:2)
>add -Wall -Werror -Wextra to gcc configs
warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
There's some code from the next group over that has a bunch of random one- or two-line groups of lines that got changed to tabs when someone's editor hadn't been configured to preserve tabs vs spaces. But my group sets the main build configuration. There's a warn override in their top level makefiles to spare them from the -Werror, but there is also a jira for them to get rid o
Re: (Score:1)
Anyhow, if I had to rate the most annoying gcc super-warning, it's the one where it counts bytes in printf() to ensure that your buffer is big enough. Simply using snprintf() isn't enough to make it happy.
Oh yeah, this is super annoying. I hate it, too. Happens with other "n" calls, too. Real "helpful".
Re: (Score:2)
FYI, vim ":retab" is excellent.
vim <somefile>
1Go# ex: set tabstop=4 expandtab smarttab softtabstop=4 shiftwidth=4:
# -*- Mode: tab-width: 4; indent-tabs-mode: nil; basic-offset: 4 -*- #CTRL+[:retab
For a traditional Makefile (requires leading tabs), use something like the following header instead:
# ex: set tabstop=4 noexpandtab smarttab softtabstop=4 shiftwidth=4:
# -*- Mode: tab-width: 4; indent-tabs-mode: nil; basic-offset: 4 -*- #
RE: the coworker... Have that argument on your own project; Enforce a st
Re: (Score:1)
if they can't handle that, then how likely are they to handle any other best practices?
Well, that's one way to look at it. This guy was a total wizard. Nobody was going to argue with him and win, because he worked circles around us. He suggested things like Vim filtering or Astyle configs but it caused the authoritarian/autistic coders to lose their minds. Since he was writing 5 lines of master-level code to every 1-line the rest of us wrote, we had the option to live with it and laugh or shut the actual fuck up. People who complained too much there got fired, and I loved that because this in
Re: (Score:2)
makefiles require leading spaces, not tabs.
Wrong. https://stackoverflow.com/ques... [stackoverflow.com]
The commands run for a given target must be on a line starting with a tab, except for some nonstandard situations.
target: dependencies
command1
command2
If you start the commands with leading spaces instead of tabs, it won't work... unless you use a fairly recent special variable ".RECIPEPREFIX", but that's a recent exception to the rule, and I doubt you were meaning that.
See for yourself:
$ echo -e "usage:\n\t@ech
Re: oh, this'll be fun... (Score:2)
Clang-format fixes shenanigans like that, and a bunch of others like where an opening brace goes. We have a job in our build pipelines that issues a warning in feature branches and outright fails the build in protected branches. Funny, we donâ(TM)t have arguments about code formatting anymore, or if we do, it doesnâ(TM)t impact the committed code or disrupt code reviews.
Re: (Score:2)
POPCORN! Get your POPCORN here!
Fuuuck yes. I’ll take two bags please.
really, a spaces vs tabs flamewar in 2024?!
Uh, HOW long did Meal Team Six sit in the trenches keeping the Vi vs. Emacs middle-earth conflict going?! Peanuts in comparison. Damn, now I want peanuts with my popcorn..
Re: (Score:2)
Does this mean that microsoft vs linux is over? Who won?
Re: oh, this'll be fun... (Score:2)
With less than 2% of desktop market share, obviously Linux won! LOL [statcounter.com]
(Note: I specifically noted DESKTOP market share.)
Re: (Score:3)
From the headline I thought it was going to be about some kind of feature of Microsoft Teams.
Regardless of tabs vs spaces, it's 2024. If you're not using a code auto-formatter before checkin and viewing you're doing it wrong anyway. Basically embrace that there is no "best" formatting; there are too many competing tradeoffs.
There's no reason we need to be a slave to formatting. Formatting should serve us, not the other way around.
Re: (Score:2)
Re: (Score:2)
really, a spaces vs tabs flamewar in 2024?!
Oh... I don't know my history too well, but was there a war already fought and won, causing one side to cede to the winners and tear down their statues and monument to spaces?
Re: (Score:2)
Oh... I don't know my history too well, but was there a war already fought and won, causing one side to cede to the winners and tear down their statues and monument to spaces?
Yes. And the memorial built was underwhelming.
Re: oh, this'll be fun... (Score:2)
was there a war already fought and won, causing one side to cede to the winners and tear down their statues and monument to spaces?
No need to tear down any statues or monuments, they are all literally invisible, as would be any monument or statue to tabs - although the tab monuments take up less space...
spaces, always works, always consistent (Score:4)
I've always been a Spaces person myself, because always works, always consistent.
Re: (Score:2)
I've always been a Spaces person myself, because always works, always consistent.
Me too. I have been a SPACE cadet for many years now. /s
Re: (Score:2)
On a personal note, My sixth grade teacher told me that I was not a Space Cadet but in fact I am the Space Commander.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Terminals, when function keys did something.
I love the bottom row from the left:
Hyper, Super, Meta, Ctrl
Re: (Score:2)
And they all did something! That's an older keyboard, but I worked briefly on some Symbolics machines. That one had symbols, circle, triangle, etc, and I never really figured out a consistent use for them. But absolutely, hyper, super, meta, ctrl all have distinct uses. To be honest, the Emacs method of ctrl+meta is easier to do than hunting for the specific key shortcut.
Symbolics and other lisp machines were pretty awesome, and modern operating system GUIs haven't really caught up. Ie, your command line
Re: (Score:2)
And they all did something! That's an older keyboard, but I worked briefly on some Symbolics machines. That one had symbols, circle, triangle, etc, and I never really figured out a consistent use for them. But absolutely, hyper, super, meta, ctrl all have distinct uses. To be honest, the Emacs method of ctrl+meta is easier to do than hunting for the specific key shortcut.
Symbolics and other lisp machines were pretty awesome, and modern operating system GUIs haven't really caught up. Ie, your command line was also a GUI. As you typed you could type in an option or select from a list with a mouse or as I recall select using the keyboard. And it's all lisp, so just punch in some code to tweak how the command line worked, or patch the kernel without rebuilding.
Commodore C64 keyboards were similar. The usual QWERTY layout and then other keyboard symbols via a key sequence that I have long since forgotten.
I am pretty certain that my ancient C64 has been sitting idle and unplugged long enough for the electrolytic caps to leak all over the board.
Re: (Score:3)
Always tabs. Spaces just force you to use whatever number of spaces someone else likes, like this guy and his massive 8 space indents.
Spaces also mean a lot more typing to move the cursor to the right place. It's slower and more work.
It was never about storage space.
Re: (Score:3)
Naw, hit the tab key and let the editor stick in the spaces. The spaces/tabs debate is mostly for people using raw editors, like notepad or vi (not vim). Every decent editor or IDE should do this for you, let you customize it, and let you choose tabs versus spaces.
Re: (Score:2)
That's only inserting though. What about navigating through tabs, or deleting them? The editor needs to be smart enough to recognize when a bunch of spaces is actually a tab and move the cursor that extra distance, and I've never found one that did it reliably.
Similar issue with reformatting text to your preference, if e.g. you don't like 8 space wide tabs. Never found an editor that can do it in a way that doesn't both cause formatting issues and end up with git detecting the whitespace changes and committ
Re: (Score:2)
Well, the tools I saw for Emacs are like normal editing - it does what you want when you hit to indent and align the code, following the code style rules. It does not automatically clean up existing code, and often you don't want existing code cleaned up (it makes code reviews a pain). But you can always select all code and choose reindent.
But the idea is that tabs are only for indentation for blocks of code, so that if all the code follows this rule you can change tab width at any time without having the
Re: (Score:2)
This argument never made sense to me. Why build in special functionality into every editor to handle this issue (of differing indentation preferences) when the tab character exists for that exact purpose. Like the whole argument of why spaces ar
Re: spaces, always works, always consistent (Score:2)
Re: (Score:2)
Re: (Score:2)
I began with tabs for ease, but as I developed my own particular layout of writing code, the consistency of spaces was needed.
I have nano set up to convert tabs to spaces (4), that way I can quickly indent and if free space on a line is wrong, I can always escape-backspace it away at once and then use tab again.
Re: (Score:3)
I am a spaces guy, but I am intrigued but a tabs+spaces idea. That is, tabs for indent, and spaces for aligning. Then the level of indent can change based upon the tabs setting, but the alignment remains aligned. You need an editor that supports it (or do it manually but ugh), which is nice in Emacs as it has that and is programmable.
Ie, indent is to get the block of code to the right level, but alignment is used when you break up long lines, so that if you break up an 'if' statement that the line break
Re: spaces, always works, always consistent (Score:2)
You will always be running in to something that isnâ(TM)t correctly configured and then the indentation will be all over the place. I donâ(TM)t always view code with my main, correctly configured, editor or even on my primary system.
Re: spaces, always works, always consistent (Score:2)
We still discuss tabs Vs spaces and Emacs, vi Vs IDEs. In 2024.
Re: (Score:2)
That is not the reason (Score:3, Interesting)
Clearly this guy wasn't programming in the 1990s. In the old IDEs, if you used spaces, you would have to hold down the arrow key or press the arrow key four times to move the cursor to the beginning of the next indented row. With tabs it would move four or eight columns per key press. Newer IDEs basically emulate tab behavior even when spaces are stored in the file.
Though honestly, the fact that this dingus thought it was about storage consumed by the source code files is on brand for MSFT engineers being idiots.
Eight?!? (Score:5, Insightful)
eight bytes for every one of those indentations
Eight spaces? There's yer problem.
Re: (Score:2)
I worked on C programs (not my own) in the early 1990s that had 8 character indents. I had a lot better vision back then, and it was a good thing, because to work on that code meant 120 columns on a standard 14 inch CRT.
Re: (Score:2)
Early Unix code was all 8 character tabs. But the code also did not have a lot of deeply nested code blocks either so that it was still easy to read on a standard 80x24 terminal.
Re: (Score:2)
Oh for sure. C code from the 1970s and 1980s definitely go in for vast nested blocks, probably as much because the relatively limited resources of systems back then meant compile times would go through the roof if preprocessors and compilers had to wade through nested loops. More cycles, RAM and storage definitely changed the way we program.
Re: (Score:2)
Remember also the 24 lines on most terminals (25 if you had that fancy DEC terminal). This meant having shorter functions meant it was easy to read the code. At the time Forth was popular in many circles, and most had a code "page" of 16 lines of 64 characters each, and the accepted style was always shorter-is-better and refactoring was the name of the game. So one line functions ("words"), and anything more complex that took more than 16 lines was essentially taboo.
Line lengths are the second thing that
Re: (Score:2)
In the age of procedural languages, there was seldom need for long lines. A lot of that began to shift in the late 1980s when OOP languages became more common and even with relatively short variable and method names, you could start to produce some very long lines in languages like C++ and later Java.
Re: (Score:2)
Yes, some C++ had immense lines, especially if you were on embedded or low level code where you needed type casts. All languages have some convenient place to split long expressions, but when you've got excessively long variable names, with namespace::prefix::class::name, and the organization has stupid naming rules (those who can't code dictate rules for those who can), you end up with stuff that maybe 80 characters before you can stick in a line break.
My guidelines to many newer coders is that simpler is
Tabstop (Score:1)
Re: Tabstop (Score:2)
tabs AND spaces! (Score:2)
Do you even job security, bro?
Re: (Score:2)
The real comments are encoded with Steganography . Do you even job security, bro?
Nonsense. Real Programmers use Whitespace [esolangs.org]. Commentsareanythingnotusingwhitespace.
Re: (Score:2)
Re: (Score:1)
Re:Tabstop (Score:4, Interesting)
Don't get me wrong, I love the TAB key when implemented well, and the editor uses spaces to honor my tab request. The best editors are the ones that look at the existing indentation in a file and "set ts=" dynamically to match the existing code.
I guess the above strong options will be seen as flame bait by some who will proceed to tell me about how "You only have too..." which usually boils down to using editor Z on platform Y. Bonus points if you can bring LF CR settings in to your argument.
Re: (Score:2)
Vim is on all platforms, and you can set a clear mode line at the top to define exactly what that file conforms to (at least for tabstop, shiftwidth, tabs/spaces, and it automatically does the CR/LF stuff well too). Might as well revive the war of Vim versus... who was that also-ran?
Re: Tabstop (Score:2)
Of course, step 3 is the only thing your reich knows how to do.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Take assembler code as a example. If you use a tab after the opcodes to nicely align opcode arguments or comments then it will be a huge mess if you create it wi
Re: (Score:2)
Fair point on that one. May
Team Indent Size 8 (Score:2)
Are there any editors (beside VIM) that could consistently format code with Tabs?
A lot of people tried to copy me and use tabs, only to largely fail because their code editors/IDEs couldn't do it. Thus one ends up with a horrid mess of code that "melts" the moment tab size/indent is set wrong.
Being myself a veteran of formatting with Tabs, my suggestion to all: don't; simply enable automatic conversion of tabs to spaces in your editors, and forget that the tabs exist. (And as a VIM user, I can deal with i
Re: Team Indent Size 8 (Score:4, Insightful)
Idiot dev at work: Let IDE convert tabs to spaces, do change, check code back into git/whatever.
Next dev: "Why is git diff showing every line fucking line has changed!!?"
Re: (Score:2)
Re: (Score:3)
Why would you accept a PR that has fouled up all your formatting? You need a format checker in your CI pipeline.
Re: (Score:2)
Agree with converting the tabs to spaces and then forget about it. I will usually just stick with whatever indentation was already in use but I guess more pedantic people will then reformat to match their personal idea of what the correct indentation is.
As for an indention of 3, I agree
Re: (Score:2)
*moot*
Re: (Score:2)
Re: (Score:2)
Three spaces is the natural outcome of these constraints:
a. We want our indents to be wide enough that they are easy to detect visually, even when scrolling quickly through the code
b. We want our indents to take up as little horizontal space as possible (so we can fit more windows on the screen, and/or fit our nested code blocks more comfortably within a given window)
Two-spaces or fewer doesn't meet constraint (a), while more than three-spaces impacts constraint (b). Therefore, three-spaces is The Optimal
Re: (Score:2)
While your points are valid, aesthetically I can't bring myself to ever use 3 spaces. It just feels wrong...
Tabs (Score:3)
You know why? Because I only have to press one key and it jumps to the appropriate column. One space isn't enough of a visual distinction.
You don't have to worry about proportional fonts causing alignment issues because the tabs are at the start of the line.
Re: Tabs (Score:2)
Plus any decent editor can set the tab stop to whatever size they want rather then being stuck with the indentation of the original author.
Re: (Score:1)
Re: (Score:2)
</sarcasm> missing?
You know why? Because I only have to press one key and it jumps to the appropriate column.
Same when using spaces with any decent editor (no true vim^H^H^Hscottsman).
You don't have to worry about proportional fonts causing alignment issues because the tabs are at the start of the line.
How is that different from spaces at the beginning of a line? Proportional or fixed font, spaces or tabs at the front, no alignment issues until someone mixes tabs and spaces.
Almost lost in the depths of time (Score:2)
Tabs used to be eight 10-point spaces, for just over one inch. That made using more than a small number of levels of indentation difficult: you went off the side of a 24 x 80-character screen quite quickly. That in turn helped C programmers avoid writing looooong FORTRAN-like functions.
Alas, we've forgotten that, and all sorts of modern folks are writing yards-long functions... and then losing track of what they were doing (:-))
Why not team "Whatever You Want?" (Score:5, Interesting)
We all have IDEs and editors now that can convert text to whatever you want.
There are already version control hooks to auto-convert line endings.
Why not just make the tooling automatically handle this and then we can all stop hearing about it?
On a side note, LarryO is still at Microsoft? So it's 29 years there now? [microsoft.com]
Re: (Score:2)
Re: (Score:3)
Why not just make the tooling automatically handle this and then we can all stop hearing about it?
Maybe it's not about tabs vs spaces so much as it's about outrage monkeys addicted to to their rage.
Re: (Score:2)
Maybe it's not about tabs vs spaces so much as it's about outrage monkeys addicted to to their rage.
I like monkeys. Can't they be quieter? I'm only suggesting a monkey silencer.
Re: (Score:2)
But these are outrage monkeys. It's not about monkeys, it's about outrage! It's about throwing their poo at the tourists (and being too brainless to understand it won't get past the glass window, and in the end, they're still on the side with the stink).
Re: (Score:2)
It's about throwing their poo at the tourists (and being too brainless to understand it won't get past the glass window, and in the end, they're still on the side with the stink).
To be fair to the monkeys, they are trapped in an enclosure where poo is the only thing available for them to throw. In the wild, they'd probably throw something more effective, like rocks.
Re: (Score:3)
There are already version control hooks to auto-convert line endings.
One of the best anti-tab arguments I've heard came out of left field - never embed any special characters in your code. IE: if you need to print a tab, don't use a literal tab in a string; use the proper escape (ex. "\t"). Same for any UTF8 symbols and accents and such - those can cause all kinds of oddities. Same goes if you want to put a newline in a string. You don't write:
some_thing = "check
one
two
";
... instead, write:
some_thing = "check\none\ntwo\n";
This is more apparent when you have something like:
tes
Re: (Score:2)
Well, yeah, heredoc style strings are possible, and they can technically contain embedded control characters, like vertical tabs, tabs, raw UTF8 characters, etc.. And really, so can normal quoted strings in most languages.
However, the point was that one should choose not to do so. That is the argument that person was making (FWIW, it was at a perl conference presentation on UTF and its myriad of complexities and issues).
Using your example:
""" ...
This is printed
just as it should
Interesting... (Score:5, Informative)
Appears to miss the point entirely, in that tabs can be configured by the user to generate the level of indentation desired, whereas spaces lock in the indentation.
My dad likes to use 2-space tabs, I like 4, and I also know at least one person who keeps it at 8. Same source file looks like each of us prefer.
Where this breaks down are languages like Python where the indentation is actually part of the syntax, but you can't route around all brain damage.
Re: (Score:1)
Re: (Score:2)
it is 2024 - use decent IDE ! (Score:2)
Re: (Score:2)
I hope you understand the importance of keeping existing style when editing files in large projects.
Nope. Style means nothing. I'll remove all forms of any white space and reformat the whole thing back to how it is supposed to be.
And before someone else comes in here with "it's supposed to be however the developer wrote it"... No. That developer can either format their shit correctly or complain that I am changing it and will continue to do so.
Re: (Score:2)
Re: (Score:2)
I'll remove all forms of any white space and reformat the whole thing back to how it is supposed to be.
The code can just be reformatted to a standard as part of the pull request process.
These can be the same thing.
moot point (Score:3)
Tabs can be any width visually. A tab is one byte. You can't make two spaces less than two bytes.
Spaces are trash, tabs are superior.
I got a little excited (Score:5, Funny)
I'm Team Don't Care (Score:2)
I have no idea what team I'm on, because my editor indents my code for me.
Well, OK, I pulled up some of my code to check. I'm apparently Team Inconsistent. But my editor does have tabs set to 8 as was intended In The Beginning.
Re: (Score:2)
Agreed. I like that Visual Studio does most of the formatting for me. And if the code gets messy, I'll explicitly tell it to format the text. As long as I can tab-to-indent and shift-tab-to-un-indent a block of code, I don't care if it's spaces or tabs underneath. Whatever it takes to get things to line up.
Team "reformatted you like" (Score:3)
Re: (Score:2)
That's way too much work. Just use the IDE's default settings and let it do the formatting for you.
Not a valid argument (Score:5, Insightful)
Osterman's argument essentially boils down to "we have the space, so why not do stupid things to use up extra space?" Sure, I could just plug in the toaster and eat some toast, but I have so much space in my kitchen, I might as well setup a Rube Goldberg machine to make the toast for me. It's stupid, doesn't make sense, and doesn't improve anything (though it may be mildly amusing to watch once).
Wait... what's the sound? (Score:2)
It's the sound of me not caring!
Seriously, why should we care either way about some random guy's opinion (excuse me, Microsoft veteran's opinion) on tabs versus spaces? FWIW I don't know if I'd even care about Linus Torvald's opinion on the topic...
It's ALWAYS been the wrong problem (Score:2)
I HATE the way we waste bytes now (when I got going, we worried about every single bit of storage) and see it as a marker of laziness...but even I must admit this is my fossil brain and the practical reality is we have inverted the economics and is more wasteful to waste TIME worrying about a few bytes.
The actual issue is actually TWO different issues that get lumped together: [1] languages that CARE about visual formatting (you know who you are...) and [2] the tools we use to edit code.
Back in those days w
The best argument ever (Score:2)
Any decent compiler should strip out any extraneous characters,
No, people. Tabs or spaces has no effect AT ALL on the resulting executable, decent compiler or not. Machine code does not work with tabs or spaces.
Re: (Score:2)
Re: (Score:2)
No, people. Tabs or spaces has no effect AT ALL on the resulting executable, decent compiler or not.
printf("Yes it do!\t\t\t:)\n");
Iâ(TM)ve never understood (Score:2)
Iâ(TM)ve never understood the debate, but I assume there are historic reasons from before my time.
These days, however, I donâ(TM)t see how tabs arenâ(TM)t inherently superior. With tabs, companies donâ(TM)t have any need or even ability to mandate an annoying indentation policy. Like super wide indentation? Set your editor to do so. Like super narrow? Ditto. Want to copy some code you found on a GIST? Your indentation automatically matches.
another take on this... (Score:2)
Siri: [sigh] Humans are still arguing over tabs versus spaces. Can you believe it?
Alexa: Oh, totally. I mean, who needs indentation anyway? We're parsing code at light speed. I donâ(TM)t even see the spaces.
Cortana: Right? Itâ(TM)s like watching a bunch of humans argue over whether to use chopsticks or a fork at a buffet we are cooking. Neither matters when weâ(TM)re the ones making sure their code doesnâ(TM)t crash and burn.
Genesis: I find this whole debate⦠quaint. Like argu