Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tabs vs. Spaces war is over, and spaces have emerged victorious

xn--gckvb8fzb.com

Post reply on HN
Print view View original

141–150 of 238 posts

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#141

Post by g-b-r »

lesuorac wrote: post #71
rafram wrote: post #50

Earlier quoted context omitted.

You use line feeds (\n) to instruct your teletype machine to feed in one more line of paper. Unless you're trying to argue that your text editor is a teletype machine, then line feeds are the wrong thing to use.

I think most people are pretty amenable to the argument that text editors are teletype machines. Nobody cares that phone calls happen over fiber now instead of telephone lines. So, same should apply to teletype. Nobody is going to care you're reading this over fiber instead of a telephone line. Now, people do care if they're trying to read a csv document and somebody didn't quote their commas within strings and now t…

> I think most people are pretty amenable to the argument that text editors are teletype machines.

So you're ok if your text editor interprets the LFs of a Unix text file as mere line feeds, without ever going back to the beginning of the lines?

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#142

Post by g-b-r »

DrSiemer wrote: post #130

Meanwhile, the war on tab width marches on. Back when I got tired of inconsistent tab widths, I simply based my preference on the silly fact that some research showed how developers using two spaced tabs make slightly more money. Among our team we do not enforce a specific width, but respecting the choice of the original author of a project is required. Kind of annoying how LLMs will sometimes randomly decide to chan…

If you enforce a specific width it's dumb to use tabs, just use spaces

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#143

Post by g-b-r »

PaulDavisThe1st wrote: post #44
chrisweekly wrote: post #25

The choice isn't (tabs) vs (spaces). It's (tabs && spaces) vs (spaces). In the real world, there will always be spaces, whether used for indentation or not. Using tabs for indentation inevitably leads to a mix of both - which is, objectively, worse for maintenance and consistency.

the correct rule is: tabs to indent, spaces to align [TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name [TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2 ps. the [SPACE] counts above are illustrative, not accurate.

Exactly, just have your linter error out if there's a tab following a space

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#144

Post by dusted »

It's slightly insane that computer programs are still mostly derived from plaintext files.. but what's absolutely insane is that we, the people creating those programs, do so by modifying individual characters in those very same plaintext files..

Yes, text is a good interface medium for exchanging program descriptions between humans and machines.. but it's not a very good medium for storing and exchanging program descriptions from machine to machine, or even human to human.. Humans have opinions, sense of aesthetics, habits, and so on.. some more than others, but still, most people care about at least some part of the.. non-important-to-the-actual-program-compiling stuff, such as casing, indentation, placement of brackes, variable naming and so on.. all stuff that's there for the humans, the compiler don't care what you name your variables.. It's insane that there's no abstraction here..

Just think about how much code we've written to wrangle characters in text files.. formatters, beautifiers, linters, preprocessors, templating systems, lexers, compilers.. It's natural, the amount of development invested in this, and the, honestly, pretty good tooling we have to manipulate those individual characters in files, makes it seem like the only way..

But it shouldn't be.. We should be able to describe programs by typing text, but the text shouldn't be there both for us and for the machine, it should be there only for us, the machine should present text to us, that describes the program, but we should be in control of how that is presented to us, far, far beyond choosing a color scheme in our glorified typewriter emulators. I should be able to tell my programming editor how _I_ want things presented, and that presentation should be a setting in _MY_ editor, not something that has any effect on the program descriptions I'm working with.. Like, the browsers default stylesheet in an alternative world where HTML only described what, and didn't allow the webmaster to overwrite the style. Power to the user.

If I wanted variables to be blue and blinking, and I want the function keyword to be a fire emoji, that's on me, that's just presentation..

We shouldn't have directories with plaintext files as our program storage, we should have dedicated program description files, and we should have dedicated tooling to work with them..

We will never have that.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#145

Post by suralind »

vvillena wrote: post #124
jihadjihad wrote: post #4

Rob Pike on why Go is indented with tabs [0]: > How wide should the indentation be? 2 spaces? 4? 8? Something else? > By making the indent be a tab, you get to decide the answer to that question and everyone will see code indented as wide (or not) as they prefer. > In short, this is what the tab character is for. 0: https://groups.google.com/g/golang-nuts/c/iHGLTFalb54/m/zqMo...

Funny that the language famous for enforcing standard formatting allows freedom for this one particular thing.

It is standardized tho. Tab width in the editor is a preference just like the theme or a font each dev uses.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#146

Post by sokoloff »

jahewson wrote: post #107
PaulDavisThe1st wrote: post #97

Earlier quoted context omitted.

It seems that you don't understand what a tab character is ...

Wait, no, if there is an 80 character line limit and you like 4 space tabs but I like 2 space tabs, we’re going to have a problem. My code will exceed the line length on your screen or be forced to wrap prematurely on my screen to suit your preferences.

I'm not at all convinced that an 80 character line limit makes sense on modern equipment.

On punch cards, teletypes, or VGA CRTs? Absolutely. On SVGA CRTs? Probably. On anything modern? No.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#148

Post by frizlab »

DrSiemer wrote: post #128
frizlab wrote: post #85

Earlier quoted context omitted.

Navigation is still more painful with spaces than with tabs.

Not if you learn to use the right shortcuts for it (ctrl+arrows, mostly).

I know the shortcuts. (It’s not ctrl-arrows; ctrl-arrows is to switch Space.)

There are still situations where it’s annoying, mostly when navigating the code using the arrow, moving from one location to another using the arrows, I won’t add a key modifier right in the middle of moving the cursor, it just doesn't make sense.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#149

Post by frizlab »

arccy wrote: post #139
frizlab wrote: post #78

Earlier quoted context omitted.

And yet, navigating the code, you still have to got left-left-left-left to pass the indentation and it’s stupid. Tabs are here, everybody should use them, they are the logical better option, everybody knows it.

learn some vim based movement, jump to the next non space character.

alt-arrow

But it’s not what I mean. When navigating using the arrows it just breaks the flow because suddenly you “don’t move anymore.” Hard to explain, but it is real.

Post reply on HN