How about "neither tabs nor spaces, and set your editor to indent according to the syntax rules of your language"?
It doesn't work for indent-sensitive languages like Python, but it works for most of the other major languages.
The Tabs vs. Spaces war is over, and spaces have emerged victorious
101–110 of 238 posts
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#102This is yet another reason why source code sb stored in parsed AST form.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#103Earlier quoted context omitted.
> so by using tab, one ... allows the developer to determine screen spacing to their comfort (Allow me to reply to this age-old argument with the age-old counter argument...) But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on…
I dont even understand what youre trying to describe here. What is a wandering right column? This argument fails by default if its not understandable.
Like if my tabs are 2 spaces and I save a file like this:
line1 = wrapped
+ to_here_max
if something:
another_line
= some_val
+ other
Then someone else loads it with tab width set to 6:
line1 = wrapped
+ to_here_max
if something:
another_line
= some_val
+ other
Of course it's not a real concern because your editor can probably automatically fix this. But if it's clever enough to do that, then the supposed extra flexibility of tabs is actually possible with spaces anyway.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#104Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#105Earlier quoted context omitted.
> another developer is seeing the code different than you. but that's the whole damn point ... I like substantively indented code, you prefer minimally indented, we should both be happy (and we can be, by using tabs).
You could certainly make that argument. You could also make the argument that all the developers on a project seeing the same view of the code enhances collaboration and team cohesion, especially if your team does pair programming. This is often why dev teams have more specific style guides that include things would be considered bike-shedding, like how many spaces an indent is.
So are we also going to have team themes, team syntax highlighting colors, team fonts, team dark/light mode, team screen resolution, etc?
Why not bikeshed the bikeshedding?
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#106Earlier quoted context omitted.
> so by using tab, one ... allows the developer to determine screen spacing to their comfort (Allow me to reply to this age-old argument with the age-old counter argument...) But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on…
> But you also have to decide at what point to hard wrap each line based on a max line length I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer. But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to ma…
[deleted]
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#107Earlier quoted context omitted.
You could certainly make that argument. You could also make the argument that all the developers on a project seeing the same view of the code enhances collaboration and team cohesion, especially if your team does pair programming. This is often why dev teams have more specific style guides that include things would be considered bike-shedding, like how many spaces an indent is.
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.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#108Earlier quoted context omitted.
I use tab at three. And will do to the day I die.
Sometimes I remember a workplace system I used, where someone had set tabs to 8 space. I don't know why it was 8, but it was.
The VAX/VMS terminals we used at university to learn Pascal defaulted to 8 space tabs, on a 80 column screen. That certainly pushed some people towards using spaces.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#109Earlier quoted context omitted.
Exactly. Indentation != spacing. And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.
> You can use tabs to indent and spaces to align after that, in most cases. In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.
Stop aligning stuff. I don’t even use a monospaced font.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#110Earlier quoted context omitted.
> so by using tab, one ... allows the developer to determine screen spacing to their comfort (Allow me to reply to this age-old argument with the age-old counter argument...) But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on…
> But you also have to decide at what point to hard wrap each line based on a max line length I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer. But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to ma…
>It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.
And then have merge conflicts between people who set different hard wrap points? Did you mean to say soft wrap point?