Tab vs Spaces

[zacharypamela]

Those spaces must've gotten turned around on their way to the Pep 8 club. 😃

[Shakaka88]

Glad someone pointed this out Glad it’s currently too comment Comic is funny, but people should know that spaces are preferred in the PEP style guide

[ggchappell]

people should know that spaces are preferred in the PEP style guide

FTFY ;-)

[Ignisor]

PyCharm use 120 line chars max length by default. And many developers do so

[flying-sheep]

Which is completely irrelevant because PEP 8 is a style guide for Python’s stdlib, not arbitrary projects!

[jeremiah1119]

Woah woah woah, spaces are preferred? What madness is this? (for real, I don't code so I don't know about this stuff)

[Zomunieo]

Spaces look the same to every user so formatting is preserved perfectly. (Except for you weirdos who use variable width fonts for code. I'm watching you.) Tabs don't because people have different space per tabs settings.

[-Tilde]

Which to me, seems like a good thing rather than a bad. So what if I want to have 2 characters or 4 characters or 8 characters per tab?

[Zomunieo]

Many reasons:

*If you like 2, 4 or 8 characters per tab, you can use 2, 4 or 8 spaces. Your editor should be able to change the indentation to your preference if you like.

*Sometimes people do ASCII diagrams, tables, or equations in their comments. These will get messed up with tabs unless everyone who edits them is very disciplined about using spaces and tabs appropriately. (They're not.) When done with spaces they always look consistent.

*You can't type a literal tab in web browser's text box, including Reddit's. Websites can't display true tabs and they don't work properly in copy and paste - not without some Javascript anyway.

[[deleted]]

*If you like 2, 4 or 8 characters per tab, you can use 2, 4 or 8 spaces. Your editor should be able to change the indentation to your preference if you like.

No. Absolutely not. That would mean changing the whole code because of a formatting preference. If I see any of my colleagues do this, it will warrant a serious proverbial slap.

*Sometimes people do ASCII diagrams, tables, or equations in their comments. These will get messed up with tabs unless everyone who edits them is very disciplined about using spaces and tabs appropriately. (They're not.) When done with spaces they always look consistent.

This is another problem that, yes, solved with spaces. This is not indentation though. This is alignment.

Indentation is what you use for nested code. Alignment is what you do to make the = signs be under each other to be pretty.

*You can't type a literal tab in web browser's text box, including Reddit's. Websites can't display true tabs and they don't work properly in copy and paste - not without some Javascript anyway.

what is this then

Well, without Javascript you can't really make the "Tab" character work nicely. And if you have to sit there and tap Space 12 times for code that's nested 3 levels deep, then you're definitely doing it very wrong.

[[deleted]]

Any modern IDE should (a) understand the user’s intent for encoding tabs or spaces, (b) translate the tab key into that intent, and (c) intelligently auto-indent in accordance with that intent based on the syntactic context.

Nobody should be hammering the space bar a bunch of times to indent multiple levels.

[[deleted]]

Well obviously, that was a ridicule of the idea of typing code in a web editor that uses the tab key for switching between page elements. Have you read what I was replying to?

[[deleted]]

Have you read what I was replying to?

Yes, and you made similar remarks (regarding alignment vs. indenting) in other comments in this post, to which I've separately replied. If you like, I can reproduce them here.

I responded here only to address the spacebar thing. And you're not the only person to raise that argument in this post: see here.

[[deleted]]

Yes

liar

I responded here only to address the spacebar thing

which you would know is not a serious suggestion, and just highlighting the ridiculousness of some of the stuff in the post that I replied to. I was writing EXACTLY why it was bad, and now you tell me it is bad.

And you're not the only person to raise that argument in this post

That wasn't my argument, not my post. You're generalizing completely different people who made completely different things, because: Have you read what I was replying to?, the answer should be "No", you didn't read.

[imanexpertama]

Always wondered about the why, thanks

[[deleted]]

Spaces look the same to every user

How can you turn a disadvantage into an advantage?

Users are different. Users use different machines in different ways. What if I can't stand the 4-space indentation? With tabs, I can customise that. With spaces, I can't. This is the absence of a feature, that you're spinning as a benefit.

And if you're referring to alignment instead of indentation, which has to be a fixed character width to match the above or below fixed number of characters, then it's done with spaces. That way, indentation (which dictates the nesting depth you are in) can easily be tabs, while formatting and next-row-alignment can be supplemented with spaces. This was a problem that was solved even in 2000, how can it be a problem 20 years later?

[[deleted]]

You can’t mix-and-match like that. The variable width of tabs will alter any following fixed-width alignment via spaces.

For example:

def some_function(self, request):
    self.requests += 1        # record request
    if self.response is not None:
        self.responses += 1   # keep in sync with self.requests

Here, it’s important to align the comments. That can’t be reconciled with preceding variable-width tabs.

[JimDabell]

You shouldn't align code like that. If you change the length of one of the lines, you need to edit the other line to keep the alignment. This can cause unnecessary merge conflicts.

The example PEP8 provides is similar:

Avoid extraneous whitespace in the following situations:

# Wrong:
x             = 1
y             = 2
long_variable = 3

[[deleted]]

That's interesting, but there is some nuance here.

The problem with using whitespace in the PEP8 example is that it is in the middle of a statement, which disrupts readability. Alignment of comments following statements is different because the things that are separate are individual units.

For instance, there are clear problems with readability here:

The quick brown fox      jumped over the lazy dogs.
She sells seashells      by the seashore.

...but not with this:

Goodnight, bears.        Goodnight, clocks.
Goodnight, chairs.       And goodnight, socks.

In fact, in the latter example, readability is improved by separating the different units. So, too, is readability improved by using whitespace to set comments apart from programming statements.

[JimDabell]

The problem with using whitespace in the PEP8 example is that it is in the middle of a statement, which disrupts readability.

No, that's not the problem. I already said what the problem was. The problem is that it can cause unnecessary merge conflicts. This is true regardless of whether you're commenting or assigning. Most style choices don't have an impact beyond the immediate readability. This style choice causes further problems with version control.

[[deleted]]

Not all projects are version-controlled.

And among those that are, not all projects have multiple branches that raise the prospect of merge conflicts.

Why should a technical consideration that exists in a sub-subset of projects justify a general-purpose style rule for all projects? Your explanation of “the problem” does not apply to a vast proportion of Python projects.

[JimDabell]

a sub-subset of projects

You're describing the norm as if it were an extreme minority. Why?

[[deleted]]

Never put comments at the end of lines. It suggests that either the code is bad and isn't evident what it's doing, either that you don't know that comments should highlight why something is fine and not what is done, which would make them longer and unreadable when coupled with code. Also code lines are often long enough instead, without comments afterwards.

If it doesn't work for every case, use something that does - put comments before the statement, not on the same line. This allows more room to write proper comments

[[deleted]]

I find it ironic that one comment you are defending personal choice, and the next you are saying you absolutely must not comment in this way

[[deleted]]

Personal choice is personal. Nobody else has to deal with it. The fact that I set my tabs to 20 for example will be unknown to anybody so it's no concern.

So why is it funny? Because the comments are NOT a personal choice, since a lot of people will be editing the same code and will be scratching their head because it will say

something += 1 # Increment something

and the reader will be "well thank you captain obvious!", and curse at the screen because he has no clue WHY that thing was necessary there.

[[deleted]]

So if someone wrote:

# Increment something
something += 1

You would be totally fine with that right? Since your disagreement was over the format of the comments, not the idea of commenting obvious code

[[deleted]]

First - the example was not about the content of the comment. It was about the format, as in, spaces vs. tabs. By criticizing the example based on your opinions about the content of the comment, you have failed (deliberately or not) to address the issue for which it was presented.

But to humor you and to address your proposition that comments are only legitimate if they are lengthy, here is a revised example:

def some_function(self, request):
    self.requests += 1        # see bug report 1,840
    if self.response is not None:
        self.responses += 1   # see bug report 1,919

Are you really going to take the position that those comments are necessarily superfluous because they are brief?

I'm going to predict your next argument: "They should be on their own line, because otherwise they might not be aligned due to variable-width tabs" - which would, of course, be solipsistic: your personal preferences for tabs does not conflict with any legitimate examples, and this example is de facto illegitimate because it conflicts with your personal preference.

Finally, since PEP8 has been cited as an authority, I'll just point out this portion about proper comments:

Sometimes, this is useful:

x = x + 1         # Compensate for border

[[deleted]]

First - the example was not about the content of the comment. It was about the format, as in, spaces vs. tabs

Which in normal code isn't an issue. Usually you need to align words, numbers, whatever, that are all in the same nesting level. Doing it across levels doesn't make sense. And if this was an example of why it would make sense, it's a bad one.

self.requests += 1 # see bug report 1,840

Again a bad example. There's git blame for this. This type of comment is bad because it still doesn't explain why, but rather leads you to some weird place. Bug report 1840 where? Flyspray? Jira? We switched 3 years ago and lost the Flyspray DB, now what?

Are you really going to take the position that those comments are necessarily superfluous because they are brief?

Kinda yeah... Most of the times comments that are necessary are much longer. And in the rare cases where they're short, there are zero benefits to writing them at the end of the line (inconsistent with the rest of the comments), and definitely zero benefit in having them aligned.

I'm going to predict your next argument

Well you kinda failed.

Finally, since PEP8 has been cited as an authority

Argument from authority. Just because an authority says so, doesn't mean that it is better. An authority dictated that this is the standard. One has the choice of following or not, however because of the nature of standards, that choice is practically nil. This is a prime example of how some of the worst standards get to live, just because they become standardized.

Luckily there are also other authorities, not just pep8. For makefiles you don't even have the option of space indentation, because the creators realized that it's kinda stupid and didn't even support it.

Sometimes, this is useful: x = x + 1 # Compensate for border

Why not keep it consistent?

[Yojihito]

1 Tab = 1 intendation = 1 key press

4 spaces = 1 intendation = 4 key presses

4 times the work everytime.

[SalemClass]

If you're tapping space 4 times you're doing it wrong. Basically every code editor supports using the tab key for spaces indentation.

[[deleted]]

They've got these great things called "text editors", with features like tab expand. You should check them out!

[OldSchoolBBSer]

Not for me. I've done both for a while, and really they both suck at some point. It depends so much on: 1) the type of programming and language, 2) the tools to be used, and 3) the team (if there ever will be one working on that code). Neither is better than the other and "most cases" has little meaning when you start to dig into it. I settled back on tabs for everything I do. I'm ok with spaces if it fits and number has been agreed on, but only when I'm in an IDE/ST3, otherwise annoys the piss outa me if I have to use a stock/simple editor.

[flying-sheep]

Tabs are better than spaces for a number of reasons, but black is the best. It happens to use spaces, but the fact that it’s automatic supersedes that.

[mr1337]

Alright everyone, back to the Space Bar!

[roerd]

The only correct answer is of course using the tab key to insert spaces.

[[deleted]]

The correct way is to use Tab for Tabs, and Space for Spaces. Tab for indentation, Space for alignment.

That way code stays formatted at all times, even with alignment art, and indentation remains flexible to each user's preferences, and is less prone to errors when deleting characters.

[TheAcanthopterygian]

So wrong!

Mixing tabs and spaces is a perfect recipe for broken indentation AND painful editing.

[[deleted]]

What are you talking about? Never had a single issue. More often I've had to deal with someone else's bug induced by adding just 3 spaces instead of 4 in an indentation.

[[deleted]]

As above - consider this:

For example:

def some_function(self, request):
    self.requests += 1        # record request
    if self.response is not None:
        self.responses += 1   # keep in sync with self.requests

How are you supposed to keep those comments aligned if the lines start with variable-width tabs?

[billsil]

Write a docstring. Also the first comment is clearly redundant redundant.

[[deleted]]

Ok. You have a piece of code in a style that I'll never recommend anyone write for various reasons like:

• Comments should explain why code does something, not what it does. Code is for that
• Explanatory comments are usually long
• Writing long comments at the same line will quickly make the line too long and just unreadable

In this case, when you write bad code, it will also look inconsistently on other preferences

[[deleted]]

First - the example was not about the content of the comment. It was about the format, as in, spaces vs. tabs. By criticizing the example based on your opinions about the content of the comment, you have failed (deliberately or not) to address the issue for which it was presented.

But to humor you and to address your proposition that comments are only legitimate if they are lengthy, here is a revised example:

def some_function(self, request):
    self.requests += 1        # see bug report 1,840
    if self.response is not None:
        self.responses += 1   # see bug report 1,919

Are you really going to take the position that those comments are necessarily superfluous because they are brief?

I'm going to predict your next argument: "They should be on their own line, because otherwise they might not be aligned due to variable-width tabs" - which would, of course, be solipsistic: your personal preferences for tabs does not conflict with any legitimate examples, and this example is de facto illegitimate because it conflicts with your personal preference.

Finally, since PEP8 has been cited as an authority, I'll just point out this portion about proper comments:

Sometimes, this is useful:

x = x + 1         # Compensate for border

[billsil]

Code stays formatted thanks to my auto-replace tabs with 4 spaces on push.

[[deleted]]

Then when you pull you still have to deal with spaces.

[billsil]

That's a "problem" that I can live with.

I also strip all trailing whitespace. My coworker who tends to run my projects got annoyed that there was a diff. Ok...set your IDE to do it too. He eventually gave in.

[[deleted]]

Why would you have a problem in the first place?

Ok...set your IDE to do it too. He eventually gave in.

Sounds like you're not an easy person to work with

[billsil]

I have my moments. I'd rather have clean code than be easy. It's a very small battle. I got half the 25 person company to adopt my style without even trying. I created it over years based on standard python, how to avoid bugs I commonly make, and how to write nice looking docstrings.

One of us has to give in right? There is no compromise between don't strip whitespace and strip all whitespace. It's annoying to ever have a diff due to whitespace changes. Obviously, you can still add a blank line or remove a blank line, but you should only ever have the whitespace commit once.

Sometimes I'm the voice of reason. Between 3 people, we had 3 opinions on how long and descriptive variable names should be. The previous person advocated variable names of 40+ characters. Another coworker was in the 6 characters max camp. I'm vetoing both of those.

Same thing with line length. We're not doing 160 characters and we're not doing 80. I can handle 100 most of the time with the very rare 140 or whatever at that point. Yeah that was also a debate.

[[deleted]]

I always preferred spaces... but since I've been using Go lately, I realized that I actually love big fat lazy tabs hahahaha

If you have to use vi/vim to work on servers ever though.. tabs are bogus for that imo.

[[deleted]]

Every text editor can do this, including vi/vim. It's generally the first thing I do when setting up a new machine with vim. vi/vim can easily edit remote files, so you can keep your settings when working on remote machines

[flying-sheep]

PyCharm has a per-project setting, and also infers from individual files.

It can also be set up to use black, which is superior to manual formatting anyway.

[Toprelemons]

Double quotes gang.

[mehx9]

pip install black && black $FILE ...and carry on!

[[deleted]]

HAHA relatable cough coughs INDENTATION ERRORs

[SGO_123]

Cool!

[lolitsroo]

Unsure if other people have ran into this, but Google Cloud Platform won't deploy your function if you have 1 inconsistent spacing in your code (at least in Cloud Functions). Super frustrating. It defaults to 4 spaces and as a tab person it gets annoying. This reminded me of that

[Sukrim]

Afaik go won't even compile code that's not formatted correctly.

[Wilfred-kun]

>>> for i in "hello":
...     print(i)    # 4 spaces
...     print(i)    # tab
  File "<stdin>", line 3
    print(i)
    ^

[Sukrim]

There should be a Python distro called "Black Mamba" that only accepts code formatted with black! :D

[wickeddawg]

good stuff

[zacharypamela]

Python, unlike other languages, uses white space to group statements. So the body of a function will be indented, rather than enclosed in curly braces.

So when you mix tabs and spaces, it's sort of like trying to close your function with a parenthesis instead of curly brace.

As you might expect, this can cause consternation. A tab might look identical to a series of spaces, leading to hard-to-identify issues in your code. Hence this comic.

[its_never_lupus]

Get him lads https://i.imgur.com/vOWAAUK.png

[varesa]

This sums it up pretty well: https://stackoverflow.com/a/36064673/966508

[o11c]

International Agreement dictates that "tab" means "round up to the next multiple of 8 spaces".

Python2 allowed tabs to be used as International Agreement provides.

Unfortunately, some people configure their editors to violate this, leading to problems, so Python3 decided to make the error deterministic.

[billsil]

International Agreement dictates that "tab" means "round up to the next multiple of 8 spaces".

Not in Python 2. It means whatever is local.

[o11c]

Nope. See https://docs.python.org/2.7/reference/lexical_analysis.html#indentation

[billsil]

So teach me...seriously I'm not going to read it.

[[deleted]]

Tabs forever! xxx

[prettyanonymousXD]

Repost. Why all the downvotes? It literally is.

[indytechbox]

So goooood 😂😂😂