You very well may want different indent depths for different mediums, sometimes even depending on the aspect ratio of the output. For example, I prefer 2 spaces on my 6:4 Chromebook and my portrait (9:16) 4k display, or when printing to an 8.5x11" page, because there's relatively less horizontal space compared to other output formats. This keeps heavily-indented lines from wrapping or getting cut off.
On the other hand, I prefer 4 when displaying on a 16:9 or 22:9 display, or when printing at 11x8.5", because there's plenty of horizontal space and it looks nicer to fill it out more. I used to prefer 8 spaces on my 22:9 display, and I know many people who still do.
TL;DR: In contexts other than editors, you may want a different indent depth anyway.
So you're saying the problem is mixing tabs and spaces for indentation. That's not a problem with tabs and tabs bring an advantage that spaces don't. You've already pointed out how using spaces doesn't fix the problem of inconsistent indent depth, what with some people using 2, 3, 4, 5, 6, or 8 spaces to indent, and some files containing multiple different space-dictated indent depths.
Using tabs solves that, and when some idiot injects spaces you fix the error. The same should be done in your "only use spaces to indent world"; when you see inconsistent indent depths, decide which one is correct and fix the lines that are incorrectly indented.
My point is, if you want consistent formatting you have to fix it anyway, so just switch to tabs in the process and keep fixing indentation errors as you find them, just as you should be doing anyway.
To put it another way, if you're leaving files with mixed tabs and spaces, you're wrong because they should never be mixed (I think we've agreed on that point, that they should never be mixed). If you're removing the tabs but leaving the spaces inconsistent, you're wrong because you still have the inconsistent indentation you're blaming on the tabs (even though you've removed them -- follow that logic, buddy, the problem ain't the damn tabs).
If you're removing the tabs and updating space-indented lines so they're all consistent, fine, that's one right way to do it. But the compromise is that you're forcing your preference of indent width on everyone else; that's what many of us take issue with. Once your indent widths are consistent, tabs alleviate that issue and everyone can have whatever indent width they want just by specifying their tab width.
Once again, either way you go you still have to fix indentation errors introduced by lazy developers, assuming you care about that. And if you don't care about that, well, why are you even discussing tab vs space in the first place?
No, I saw it, you're just wrong. If you understood the problem you were trying to solve, you would see that. The problem wasn't the tab characters in the files, it was that you had your editor set to treat them as 8 spaces rather than your preferred indent width.
Instead of forcing a compromise on everyone else, use your tools properly.
Working with spaces is nearly identical if you set up your editor correctly. If I hit tab, it inserts enough spaces to go to the next tabstop, which I have set to 4.
And when I have mine set to 2? Do you not see a problem there? Let me explain.
Your indents, then, all look too wide to me, and mine all look too narrow to you.
If we used tabs, though, all of your indents would appear 2 spaces wide to me and all of mine would appear 4 spaces wide to you.
Precisely why I use tabs. I like 4 (or 2 depending on display dimensions as 4 can push heavily nested code off screen or off page), but some people like 3, 5, 6, 8, or whatever else. With tabs, whoever is looking at my code can decide how far it should be indented; and that includes me if I'm on my 6:4 display ratio Chromebook or printing to a portrait-orientation page.
That way, nobody has to argue about indentation width as we can all choose what we like.
The common argument against tabs is that someone inevitably slips a series of space-indented lines into the code and it no longer lines up if you change your tab width from whatever they were using when it happened. That's not an argument against tabs (which are consistent with the user's tab-width preference), though; it's an argument for replacing the erroneously-added spaces with tabs when you find them.
Any good IDE or editor will actually tell you when there are mixed tabs and spaces in a file and offer to fix it for you, even, so it's not even any extra work.
Which is also what happens when the code is cat'ed on a terminal, looked at in a diff program
Your terminal doesn't honor the control code emitted by the tabs command? Sounds like you need to find a POSIX compliant terminal; then, your tabs can be whatever width you like.
Otherwise we would never have had the initial spaces vs tabs discussion
I still don't know why that discussion ever started in the first place. We use the TAB key to indent, why should that ever insert SPACES?! That's what the SPACE bar is for; TAB should insert tabs. End of story, amirite?
What the hell kind of broken "tools" are you using? Just try what I said, you might be pleasantly surprised. Again, I fall squarely in the category of "people with experience", I have, in fact, encountered what you are talking about and I am trying to point out a solution. Hunor me and learn something, or keep arguing and remain ignorant, it's ultimately your ego's call, but you're never too old or experienced to learn a new trick.
Except that it is only semantically one indent level to you. To other people the tab is used differently. There's no standard here.
No, in truth there is a standard. You press the tab key once (or hit the spacebar X number of times, where X is your preferred indent width) to increase your indent level by 1. That's been the standard on every project I've ever touched; nobody indents by more than one tab at a time.
Using tab the way you described, if done universally, would resolve a lot of problems.
Indeed it would, which is why I advocate for the use of TAB for indents, and replace spaces as I find them.
However what actually happens is that people don't use them the same way and you end up with screwed up files with a mix of tabs and space and a mix of different tab stop settings.
In truth, that only happens when people indent with spaces. You get one guy who configures his editor to insert 2 spaces when he hits TAB, another who configures his editor for 4, and that oddball who just sues the spacebar and manually indents with 3, and now you've got 3 different standards in one file. If everyone just used fucking tabs, the guy who likes 2 would have 2, the guy who likes 4 would have 4, and the oddball could have his 3, with nobody having to engage in a pissing match over who is right or decide between enduring someone else's indent width or updating the file to match their own.
If you have to split a line (and you usually do because line length limits should apply) then you have to deal with aligning the broken parts of the line and you can't do that with just straight up indentation depending upon the coding style in use.
Right, you indent to the same level with tabs, then align with spaces. Of course, you have to use the same definition of "indent" and "align" as the rest of the industry to understand how that works.
That code review you mentioned in the other thread, go grab that, I want you to try something. You said some lines were indented with 3 spaces, some with 4, and some with 8. Pick one of those values, any one, it doesn't matter, and replace all the tabs in that code with that number of spaces. Now open it in your code review tool and tell me, does that file look any better now that it's only indented with spaces? Or is the alignment still fucked up?
If you really want to see the light, go through that same code and replace the spaces used for indentation with tabs, one for each level of indentation. Since the file has mixed indentation widths, you'll have to manually do this; 1 tab for every 3 spaces on lines indented with 3 spaces, 1 tab for every 4 on lines indented with 4 spaces, and 1 tab for every 8 spaces on lines indented with 8. Once that's done, look at it again in your code review tool.
How does that suit you? It probably looks a lot more even and structured, right?
I the width of your tab matters, you're using tabs wrong. Period.
There is a reason I asked you in the other thread to show me what you're talking about. IT is so that I can point out the real cause of the problem.
Your comment in that thread that "experience is key" leads me to believe that you think I'm new to this. Boy, I've literally been programming since I was 5. Your mention of 30-40 years of experience leads me to believe that you may be older than me, as I fall at the lower end of that range, but the level of understanding you display renders you a boy in my mind.
To me alignment means the start of each line, not aligning arguments (though the problem is there also).
To the rest of the industry, alignment is aligning attributes, arguments, operators, or, well... anything else found in the middle of a series of lines.
How far a line is indented is alignment.
No, that's indentation. At least, that's what the rest of the industry calls it
And the problem you're complaining about, where some lines are indented with tabs and others indented with spaces, and those with spaces use varying indent widths, is solved by using tabs. The problem is that tabs and spaces are mixed in the same file.
Proof: Even if all lines were indented with spaces, the space-indented lines are still inconsistent.
The problem isn't the use of tabs, the problem is the inconsistent use of spaces and, restating the above in a different way, you would still have that problem regardless of the tabs. Tab indenting is the solution, in this case.
There's a difference between positive outcome and negative outcome events. The actions I listed (holding a door for someone, covering part of someone's grocery bill) were positive outcome events and, no, you should not default to assigning racist, sexist, or other bigoted intentions to people who act toward positive outcomes.
It's a bit different with negative outcome events, but you should still have at least some bit of evidence before you publicly call out someone as racist and potentially end their career, for the very same reason police are required to have some sort of evidence before ruining your life by charging you with a crime. If you disagree with that, please consider that, in such a world where it becomes acceptable to make open and public accusations with no evidence, I could have you labeled a sexist, racist, anti-gay, child rapist.
Do you want any of those labels? If not, it is best to uphold some standard of evidence for accusations.
We do need to recognize that racism and sexism are occurring.
Indeed we do. We need to recognize when they are happening, as well, and not go around accusing everyone who interacts with anyone of a different race, gender, religion, or sexual preference of being a bigot. All that leads to is people avoiding those of different races, genders, religions, and sexual orientations, dehumanizing them, and causing more bigoted thoughts and actions when those encounters can't be avoided.
It's a slipper slope, accusing someone with no evidence.
In other words, call it out when you see it, not just when you perceive it. Kind of like how one might consider it acceptable for a cop to shoot a suspect he sees aiming a gun at someone, but not acceptable for the same cop to shoot the same suspect holding a phone the cop thinks is a gun.
How, exactly, do tabs mess up alignment? You shouldn't be aligning things at different indentation levels in the first place... If, for some reason, you find yourself needing to do that, then yes, I suppose you should just use spaces.
When I say "alignment" I mean aligning arguments in a function call that has been split to multiple lines (and thus will be at the same indentation level), aligning operators in an IF statement that has been split onto multiple lines (and thus will be at the same indentation level), and things like that. If tabs are messing with that, you're using them way wrong.
When two lines of code are indented to the same depth, how (or how far) they're indented becomes irrelevant; you could pull them out of their current context, remove any indentation, and alignment wouldn't be affected. You could indent them by 1 space, or by 100, and alignment would not be affected.
Can you please show me an example of what you're talking about, as I'm now thoroughly intrigued.
Slashdot Mirror
I don't.
I meant he collective "you". Someone might; in fact, someone does. Drop the ego and stop imposing your preferences on others.
Plus, I make more money than you :P
Is that before or after I cut payroll checks? Put another way, I highly doubt that.
You very well may want different indent depths for different mediums, sometimes even depending on the aspect ratio of the output. For example, I prefer 2 spaces on my 6:4 Chromebook and my portrait (9:16) 4k display, or when printing to an 8.5x11" page, because there's relatively less horizontal space compared to other output formats. This keeps heavily-indented lines from wrapping or getting cut off.
On the other hand, I prefer 4 when displaying on a 16:9 or 22:9 display, or when printing at 11x8.5", because there's plenty of horizontal space and it looks nicer to fill it out more. I used to prefer 8 spaces on my 22:9 display, and I know many people who still do.
TL;DR: In contexts other than editors, you may want a different indent depth anyway.
So you're saying the problem is mixing tabs and spaces for indentation. That's not a problem with tabs and tabs bring an advantage that spaces don't. You've already pointed out how using spaces doesn't fix the problem of inconsistent indent depth, what with some people using 2, 3, 4, 5, 6, or 8 spaces to indent, and some files containing multiple different space-dictated indent depths.
Using tabs solves that, and when some idiot injects spaces you fix the error. The same should be done in your "only use spaces to indent world"; when you see inconsistent indent depths, decide which one is correct and fix the lines that are incorrectly indented.
My point is, if you want consistent formatting you have to fix it anyway, so just switch to tabs in the process and keep fixing indentation errors as you find them, just as you should be doing anyway.
To put it another way, if you're leaving files with mixed tabs and spaces, you're wrong because they should never be mixed (I think we've agreed on that point, that they should never be mixed). If you're removing the tabs but leaving the spaces inconsistent, you're wrong because you still have the inconsistent indentation you're blaming on the tabs (even though you've removed them -- follow that logic, buddy, the problem ain't the damn tabs).
If you're removing the tabs and updating space-indented lines so they're all consistent, fine, that's one right way to do it. But the compromise is that you're forcing your preference of indent width on everyone else; that's what many of us take issue with. Once your indent widths are consistent, tabs alleviate that issue and everyone can have whatever indent width they want just by specifying their tab width.
Once again, either way you go you still have to fix indentation errors introduced by lazy developers, assuming you care about that. And if you don't care about that, well, why are you even discussing tab vs space in the first place?
No, I saw it, you're just wrong. If you understood the problem you were trying to solve, you would see that. The problem wasn't the tab characters in the files, it was that you had your editor set to treat them as 8 spaces rather than your preferred indent width.
Instead of forcing a compromise on everyone else, use your tools properly.
Bingo. I probably don't use the same editor as you and, even if I do, I probably don't want your settings.
Then you correct the mistake made by the person who used spaces. Problem solved.
Working with spaces is nearly identical if you set up your editor correctly. If I hit tab, it inserts enough spaces to go to the next tabstop, which I have set to 4.
And when I have mine set to 2? Do you not see a problem there? Let me explain.
Your indents, then, all look too wide to me, and mine all look too narrow to you.
If we used tabs, though, all of your indents would appear 2 spaces wide to me and all of mine would appear 4 spaces wide to you.
Precisely why I use tabs. I like 4 (or 2 depending on display dimensions as 4 can push heavily nested code off screen or off page), but some people like 3, 5, 6, 8, or whatever else. With tabs, whoever is looking at my code can decide how far it should be indented; and that includes me if I'm on my 6:4 display ratio Chromebook or printing to a portrait-orientation page.
That way, nobody has to argue about indentation width as we can all choose what we like.
The common argument against tabs is that someone inevitably slips a series of space-indented lines into the code and it no longer lines up if you change your tab width from whatever they were using when it happened. That's not an argument against tabs (which are consistent with the user's tab-width preference), though; it's an argument for replacing the erroneously-added spaces with tabs when you find them.
Any good IDE or editor will actually tell you when there are mixed tabs and spaces in a file and offer to fix it for you, even, so it's not even any extra work.
Which is also what happens when the code is cat'ed on a terminal, looked at in a diff program
Your terminal doesn't honor the control code emitted by the tabs command? Sounds like you need to find a POSIX compliant terminal; then, your tabs can be whatever width you like.
No, because we're discussing professional developers. Using spaces won't help in that scenario, anyway.
YES! This is the one true way.
Otherwise we would never have had the initial spaces vs tabs discussion
I still don't know why that discussion ever started in the first place. We use the TAB key to indent, why should that ever insert SPACES?! That's what the SPACE bar is for; TAB should insert tabs. End of story, amirite?
I knew there was something I liked about you...
So... the right answer is spaces.
Actually...
So then I told my editor to reformat and replace all the tabs with appropriate numbers of spaces....
The correct answer would have been to tell your editor to make tabs X spaces wide, where X is the number of spaces you wanted to indent by.
It did mean that people couldn't easily use different indentation levels, but that's a small price to pay.
And a price that would not have to have been paid had you properly understood the problem.
Unfortunately what they don't do is preserve the original formatting mechanism for future checkins.
Well, that's what you stated as "the answer" and that's what I was asking.
What the hell kind of broken "tools" are you using? Just try what I said, you might be pleasantly surprised. Again, I fall squarely in the category of "people with experience", I have, in fact, encountered what you are talking about and I am trying to point out a solution. Hunor me and learn something, or keep arguing and remain ignorant, it's ultimately your ego's call, but you're never too old or experienced to learn a new trick.
What the hell editor are you using that doesn't assume a single tab width?
Except that it is only semantically one indent level to you. To other people the tab is used differently. There's no standard here.
No, in truth there is a standard. You press the tab key once (or hit the spacebar X number of times, where X is your preferred indent width) to increase your indent level by 1. That's been the standard on every project I've ever touched; nobody indents by more than one tab at a time.
Using tab the way you described, if done universally, would resolve a lot of problems.
Indeed it would, which is why I advocate for the use of TAB for indents, and replace spaces as I find them.
However what actually happens is that people don't use them the same way and you end up with screwed up files with a mix of tabs and space and a mix of different tab stop settings.
In truth, that only happens when people indent with spaces. You get one guy who configures his editor to insert 2 spaces when he hits TAB, another who configures his editor for 4, and that oddball who just sues the spacebar and manually indents with 3, and now you've got 3 different standards in one file. If everyone just used fucking tabs, the guy who likes 2 would have 2, the guy who likes 4 would have 4, and the oddball could have his 3, with nobody having to engage in a pissing match over who is right or decide between enduring someone else's indent width or updating the file to match their own.
If you have to split a line (and you usually do because line length limits should apply) then you have to deal with aligning the broken parts of the line and you can't do that with just straight up indentation depending upon the coding style in use.
Right, you indent to the same level with tabs, then align with spaces. Of course, you have to use the same definition of "indent" and "align" as the rest of the industry to understand how that works.
That code review you mentioned in the other thread, go grab that, I want you to try something. You said some lines were indented with 3 spaces, some with 4, and some with 8. Pick one of those values, any one, it doesn't matter, and replace all the tabs in that code with that number of spaces. Now open it in your code review tool and tell me, does that file look any better now that it's only indented with spaces? Or is the alignment still fucked up?
If you really want to see the light, go through that same code and replace the spaces used for indentation with tabs, one for each level of indentation. Since the file has mixed indentation widths, you'll have to manually do this; 1 tab for every 3 spaces on lines indented with 3 spaces, 1 tab for every 4 on lines indented with 4 spaces, and 1 tab for every 8 spaces on lines indented with 8. Once that's done, look at it again in your code review tool.
How does that suit you? It probably looks a lot more even and structured, right?
Dude, he talks about "[dealing] with code for 30 to 40 years" but he just doesn't get it. I think we're both wasting our time.
I the width of your tab matters, you're using tabs wrong. Period.
There is a reason I asked you in the other thread to show me what you're talking about. IT is so that I can point out the real cause of the problem.
Your comment in that thread that "experience is key" leads me to believe that you think I'm new to this. Boy, I've literally been programming since I was 5. Your mention of 30-40 years of experience leads me to believe that you may be older than me, as I fall at the lower end of that range, but the level of understanding you display renders you a boy in my mind.
To me alignment means the start of each line, not aligning arguments (though the problem is there also).
To the rest of the industry, alignment is aligning attributes, arguments, operators, or, well... anything else found in the middle of a series of lines.
How far a line is indented is alignment.
No, that's indentation. At least, that's what the rest of the industry calls it
And the problem you're complaining about, where some lines are indented with tabs and others indented with spaces, and those with spaces use varying indent widths, is solved by using tabs. The problem is that tabs and spaces are mixed in the same file.
Proof: Even if all lines were indented with spaces, the space-indented lines are still inconsistent.
The problem isn't the use of tabs, the problem is the inconsistent use of spaces and, restating the above in a different way, you would still have that problem regardless of the tabs. Tab indenting is the solution, in this case.
It's a bit different with negative outcome events, but you should still have at least some bit of evidence before you publicly call out someone as racist and potentially end their career, for the very same reason police are required to have some sort of evidence before ruining your life by charging you with a crime. If you disagree with that, please consider that, in such a world where it becomes acceptable to make open and public accusations with no evidence, I could have you labeled a sexist, racist, anti-gay, child rapist.
Do you want any of those labels? If not, it is best to uphold some standard of evidence for accusations.
We do need to recognize that racism and sexism are occurring.
Indeed we do. We need to recognize when they are happening, as well, and not go around accusing everyone who interacts with anyone of a different race, gender, religion, or sexual preference of being a bigot. All that leads to is people avoiding those of different races, genders, religions, and sexual orientations, dehumanizing them, and causing more bigoted thoughts and actions when those encounters can't be avoided.
It's a slipper slope, accusing someone with no evidence.
In other words, call it out when you see it, not just when you perceive it. Kind of like how one might consider it acceptable for a cop to shoot a suspect he sees aiming a gun at someone, but not acceptable for the same cop to shoot the same suspect holding a phone the cop thinks is a gun.
If you're not reviewing your codebase regularly for old or dead code, you're in for a world of pain down the road.
Yes, I realize that it is not considered "normal" to do this; that doesn't mean it shouldn't be done.
How, exactly, do tabs mess up alignment? You shouldn't be aligning things at different indentation levels in the first place... If, for some reason, you find yourself needing to do that, then yes, I suppose you should just use spaces.
When I say "alignment" I mean aligning arguments in a function call that has been split to multiple lines (and thus will be at the same indentation level), aligning operators in an IF statement that has been split onto multiple lines (and thus will be at the same indentation level), and things like that. If tabs are messing with that, you're using them way wrong.
When two lines of code are indented to the same depth, how (or how far) they're indented becomes irrelevant; you could pull them out of their current context, remove any indentation, and alignment wouldn't be affected. You could indent them by 1 space, or by 100, and alignment would not be affected.
Can you please show me an example of what you're talking about, as I'm now thoroughly intrigued.
... "We write it", we don't... right... it... FML...