4 ms·

> This is exactly why I use tabs and the reason which appears to never get cited in the holy wars. I see this cited every time. Unfortunately, it's bogus in pr

> This is exactly why I use tabs and the reason which appears to never get cited in the holy wars. I see this cited every time. Unfortunately, it's bogus in practice. Consider: print('some long thing', further, arguments) If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news. Additionally, if you try to actually type in the six spaces, editors might take, say, four of them and group them into a tab. (I have vague memories from a long time ago of Emacs doing this. I might be wrong.) If you get this wrong in program parts that are by definition invisible, it might look good for you and look really bad for others (i.e., the opposite of the stated goal). In code I see mixing spaces and tabs, the latter tends to be the case.

gcb0 9y ago
you're going to be downvoted by the thou shalt not mix tabs and spaces crowd that fails to understand the reason of what they preach. sigh. also the fly by night devs who still don't see tabs on their text editors... I mean, ide.
pseudalopex 9y ago
Yes, Emacs used to group spaces into tabs. I think most editors these days do the right thing. This problem goes away if you indent parameters instead of aligning them: print( 'some long thing', further, arguments) In this case it takes an extra line, but it's often shorter.[1] [1] https://github.com/pennersr/django-allauth/blob/a44134688f5be0a26f5e93b607f8c4e3f5b0782b/allauth/account/views.py#L685-L688 https://github.com/pennersr/django-allauth/blob/a44134688f5b...
- sqeaky 9y ago
  Gross, You purt 3 parameters are on two lines. Either indent none of them and keep it on one line or indent all of them. What are you doing, trying to hide "arguments"?
  - pseudalopex 9y ago
    That's how the original example was formatted. I'm illustrating one small change.
news_to_me 9y ago
I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs. That being said, this problem and problems like it can be solved simply by not aligning things visually: print( 'some long thing', further, arguments ) Strictly adhering to indentation and never alignment can make the code a bit less readable, but conforming to a canonical indentation like this also makes it easier to reindent, move code around, etc. I think that's what the argument really comes down to – alignment flexibility vs display flexibility. It's interesting to see which people generally prefer.
- tom_mellior 9y ago
  > can make the code a bit less readable Yes, and I'd say that that's a big problem. I'm not a religious opponent of tabs, but making code less readable just so you can keep using them wouldn't fly if I were Malevolent Whitespace Dictator For Life.
  - striking 9y ago
    IMO, that reads just as well. Each object is still indented, it's close enough.
- pera 9y ago
  > I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs. Could you please clarify why do you consider "tabs for indentation, spaces for alignment" such a bad practice? I have never read any argument against it. Alignment itself can be done automatically by any editor that supports smart tabs.
  - Stratoscope 9y ago
    It's not that "tabs for indentation, spaces for alignment" is a bad practice, it's that alignment itself is a bad practice. It doesn't help readability, it directly causes overly long lines of code (which pushes people to try to use narrow indentation to compensate), it's something you have to fiddle with every time you refactor a name, and it gives you spurious changes in your VCS diffs. (Yes, you can set any diff program to ignore whitespace changes, but I want to know when whitespace has changed.)
z3t4 9y ago
I wonder how much time have been wasted trying to make margins and columns look good with a proportional (non-monospace) font ...
- Stratoscope 9y ago
  Almost certainly none at all. Those of us who use proportional fonts simply don't try to do column alignment, because it would be a fool's errand. In most situations, I consider column alignment to be detrimental to code maintainability. I actually stopped using it long before I switched to a proportional font. When I later got curious about trying different fonts, I discovered to my surprise that the code looked just the same in a proportional font as it did in a monospaced font. Regarding margins, if you mean indentation, that works the same in a proportional or monospaced font. The only thing that doesn't work well is the popular two-space indents. That ends up with very little visible indentation in a proportional font. But to my eyes, two spaces isn't enough in a monospaced font either. It's just not enough spacing for me to see the code structure clearly. Four-space indents solve this problem; tabs solve it even better. When you use tabs, you don't have to argue about how many spaces to use. I think these are related. Why do people want to use two-space indents? I believe it is often because their lines of code are getting too long. Why are the lines getting too long? Often that is because of the use of column alignment, especially with function arguments and the like. If you stop using column alignment, your lines will naturally be shorter, and there is less reason to try to save horizontal space with narrow indents.
mikejmoffitt 9y ago
This is an example of where it's absolutely okay to mix tabs and spaces. If it's Python, that's not going to work, but depending on one's preferences and opinions that can be seen as a defect of the language, not the formatting. In C, C++, Java, Javascript, and nearly every other language, this is a great practice.
- tom_mellior 9y ago
  I agree in theory. Having seen terrible mixes of tabs and spaces, I don't agree in practice. I've worked with several projects that painfully switched from tabs to spaces because tabs didn't work for them in practice, in a setting where several people work on one thing. I haven't seen projects go the other way. (Yes, automated formatting would solve part of thise.)
u801e 9y ago
> I see this cited every time. Unfortunately, it's bogus in practice. Consider: > > print('some long thing', > further, arguments) > > If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news. One way to avoid this would be use a hanging indent. For example: print( 'some long thing', further, arguments) That would work well with either tabs or spaces.
- Sammi 9y ago
  This is the right way to do it always, because it is the consistent way. You'll always be indenting the same way everywhere if you do it like this.
hibbelig 9y ago
I feel it's a matter of style. I've resisted a long time, but then I've come to appreciate: some_function_name('some long thing', further, arguments) Assuming a tab width of four, there is no problem with starting the second line with a tab. And the whole thing can be indented by tabs, as well (in which case the first line has N tabs and the second line has N+1 tabs). The longer the function name, the better the advantage of indenting like this.
sicariusnoctis 9y ago
Spaces are only beneficial if you use styles with alignment. I dislike them: they sometimes look pretty, but they waste a ton of space on the left and don't work well in all situations.

gcb0 9y ago

you're going to be downvoted by the thou shalt not mix tabs and spaces crowd that fails to understand the reason of what they preach. sigh. also the fly by night devs who still don't see tabs on their text editors... I mean, ide.

pseudalopex 9y ago

Yes, Emacs used to group spaces into tabs. I think most editors these days do the right thing. This problem goes away if you indent parameters instead of aligning them: print( 'some long thing', further, arguments) In this case it takes an extra line, but it's often shorter.[1] [1] https://github.com/pennersr/django-allauth/blob/a44134688f5be0a26f5e93b607f8c4e3f5b0782b/allauth/account/views.py#L685-L688 https://github.com/pennersr/django-allauth/blob/a44134688f5b...

sqeaky 9y ago
Gross, You purt 3 parameters are on two lines. Either indent none of them and keep it on one line or indent all of them. What are you doing, trying to hide "arguments"?
- pseudalopex 9y ago
  That's how the original example was formatted. I'm illustrating one small change.

news_to_me 9y ago

I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs. That being said, this problem and problems like it can be solved simply by not aligning things visually: print( 'some long thing', further, arguments ) Strictly adhering to indentation and never alignment can make the code a bit less readable, but conforming to a canonical indentation like this also makes it easier to reindent, move code around, etc. I think that's what the argument really comes down to – alignment flexibility vs display flexibility. It's interesting to see which people generally prefer.

tom_mellior 9y ago
> can make the code a bit less readable Yes, and I'd say that that's a big problem. I'm not a religious opponent of tabs, but making code less readable just so you can keep using them wouldn't fly if I were Malevolent Whitespace Dictator For Life.
- striking 9y ago
  IMO, that reads just as well. Each object is still indented, it's close enough.
pera 9y ago
> I'm pretty sure there's a circle of hell specifically for those who mix spaces and tabs. Could you please clarify why do you consider "tabs for indentation, spaces for alignment" such a bad practice? I have never read any argument against it. Alignment itself can be done automatically by any editor that supports smart tabs.
- Stratoscope 9y ago
  It's not that "tabs for indentation, spaces for alignment" is a bad practice, it's that alignment itself is a bad practice. It doesn't help readability, it directly causes overly long lines of code (which pushes people to try to use narrow indentation to compensate), it's something you have to fiddle with every time you refactor a name, and it gives you spurious changes in your VCS diffs. (Yes, you can set any diff program to ignore whitespace changes, but I want to know when whitespace has changed.)

z3t4 9y ago

I wonder how much time have been wasted trying to make margins and columns look good with a proportional (non-monospace) font ...

Stratoscope 9y ago
Almost certainly none at all. Those of us who use proportional fonts simply don't try to do column alignment, because it would be a fool's errand. In most situations, I consider column alignment to be detrimental to code maintainability. I actually stopped using it long before I switched to a proportional font. When I later got curious about trying different fonts, I discovered to my surprise that the code looked just the same in a proportional font as it did in a monospaced font. Regarding margins, if you mean indentation, that works the same in a proportional or monospaced font. The only thing that doesn't work well is the popular two-space indents. That ends up with very little visible indentation in a proportional font. But to my eyes, two spaces isn't enough in a monospaced font either. It's just not enough spacing for me to see the code structure clearly. Four-space indents solve this problem; tabs solve it even better. When you use tabs, you don't have to argue about how many spaces to use. I think these are related. Why do people want to use two-space indents? I believe it is often because their lines of code are getting too long. Why are the lines getting too long? Often that is because of the use of column alignment, especially with function arguments and the like. If you stop using column alignment, your lines will naturally be shorter, and there is less reason to try to save horizontal space with narrow indents.

mikejmoffitt 9y ago

This is an example of where it's absolutely okay to mix tabs and spaces. If it's Python, that's not going to work, but depending on one's preferences and opinions that can be seen as a defect of the language, not the formatting. In C, C++, Java, Javascript, and nearly every other language, this is a great practice.

tom_mellior 9y ago
I agree in theory. Having seen terrible mixes of tabs and spaces, I don't agree in practice. I've worked with several projects that painfully switched from tabs to spaces because tabs didn't work for them in practice, in a setting where several people work on one thing. I haven't seen projects go the other way. (Yes, automated formatting would solve part of thise.)

u801e 9y ago

> I see this cited every time. Unfortunately, it's bogus in practice. Consider: > > print('some long thing', > further, arguments) > > If this is an indented block, you'd have to indent the second line to the correct depth with tabs, then add exactly six spaces for alignment. You have to mix spaces and tabs, which is never good news. One way to avoid this would be use a hanging indent. For example: print( 'some long thing', further, arguments) That would work well with either tabs or spaces.

Sammi 9y ago
This is the right way to do it always, because it is the consistent way. You'll always be indenting the same way everywhere if you do it like this.

hibbelig 9y ago

I feel it's a matter of style. I've resisted a long time, but then I've come to appreciate: some_function_name('some long thing', further, arguments) Assuming a tab width of four, there is no problem with starting the second line with a tab. And the whole thing can be indented by tabs, as well (in which case the first line has N tabs and the second line has N+1 tabs). The longer the function name, the better the advantage of indenting like this.

sicariusnoctis 9y ago

Spaces are only beneficial if you use styles with alignment. I dislike them: they sometimes look pretty, but they waste a ton of space on the left and don't work well in all situations.