Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Tabs vs Spaces lets give this a go

by EvanCarroll (Chaplain)
on Oct 08, 2006 at 04:50 UTC ( #576936=perlmeditation: print w/replies, xml ) Need Help??

My arguement in favor of tabs

OK this is really getting on my nerves, not that people don't follow my convention, as much as people thinking their wrong convention is more righteous than mine. So I'm going to sum up the case, of spaces vs. indentation. I'll start out this diatribe by stating this is pro-tab, and DC is undeniably wrong, this is the most blatant flaw in the PBP.

  1. Tabs belong in one place in a document; and that place only. That place is in between the left-margin and the first word character. This is the tab-zone.
  2. Nothing other than tabs, belong in this tab-zone
  3. This tab-zone encodes not display, but tabs as code-metadata, the level of indentation for your code or depth, which for my purposes can be used interchangeably.
  4. This metadata can be utilized by external code preprocessors, editors, renderers, searching mechanisms or anything of that sort.
  5. Because you are encoding a level of indentation rather than an element of presentation everyone with a decent modern editor can have their cake and eat it too. ie. you can set your presentational tab-space, or tabspace to 2, your friend can set it to 4, or you can have a script based on the time of day alternate it. It doesn't mater. This will eliminate the conversion toandfro spaces. Changing this indentation will still permit all operators to line up, they will just be shifted more, and that shift will be linear to their level of indentation.

Let me explain further why this metadata is important. Lets say you want to target where in your document the sub foo {} is. You preform a search on's nifty codesearch, it yeilds what?, line 50, char X.

Should X include those spaces, or not? If so how many should it assume for each level of what appears visually as indentation? Should it display depth? You might make the argument that a line should only be 80characters? (or 78 if you are an O'reilly author who likes to justify modern coding practices with terminals from the 60s'. But thats alltogether a different argument, to which I personally subscribe, but because of preference rather than false-reasoning. ) The answer is oblivious to the length of the line, whither it be 5000 characters or 50 characters, the x-axis is important, and by using spaces to encode depth as presentation you are dually losing data, you no longer know the level of indentation, and you now have to assume what the programmer meant through heuristics.

This is all a fault of spaces, and the lack of a universal space->depth variable, but then again, spaces are being used in this context to alternate the presentation, which is fundamentally wrong. Another thing I would like to point out is something the space-proponents like to take advantage of, and it is often moot because it is an undeniable evil, and that is spaces do mark something up, and that is something we all use  @words = split ' ', "foo bar baz" it is unfortunate we use them at all for presentation. But lets not make the same mistake for tabs.

Now finally the catch, I admit there is one thing I have neglected. The only fault in this argument is minor and disappearing more every day, and that is legacy editors, or non-programming editors. Lets be blunt now:
Qualitatively how useful is a programmer who uses notepad?, What does it say about a programmer who uses notepad?, How productive can the programmer be if he opts to use tools that are so inept in the productivity dept?

You are only as good as your tools, "\t" is one that shouldn't be neglected.

I have removed responses from this node and added them to subnodes to satisify the node's fans.

Evan Carroll

Replies are listed 'Best First'.
Re: Tabs vs Spaces lets give this a go
by GrandFather (Sage) on Oct 08, 2006 at 06:03 UTC

    Tab characters should never be used in source code. They are far too prone to being abused. Traditionally a tab character was 8 spaces wide. Almost no one uses 8 character indents so a common convention is to set the expansion width of tab characters in editors to the indent width currently being used. After a little editing some of the indent tabs will turn into spaces. After that all hell breaks loose when you share the code with a friend or workmate.

    At least space indented code is presented in similar fashion by virtually all rendering systems. That is not true at all for tab indented code.

    If you have a real need to alter the indentation of space indented code use a pretty printer appropriate to the language it is written in. If there isn't one available you could pretty quickly write a Perl script to figure out the indent quanta and change it to your preferred size.

    Remember the golden rule - never use tabs for indentation.

    DWIM is Perl's answer to Gödel
      Tab characters should never be used in source code. They are far too prone to being abused.

      Perl is also prone to being abused, should we swich to python?

      Remember the golden rule - never use tabs for indentation.

      The golden rule is never mix the twp and everyone is happy.

        No. Perl is abused in amusing and educational ways. Python uses indentation in obscene ways that exacerbate the tab issue beyond reason. :-)

        Actually the golden rule is: "He who has the gold rules". All Evan actually has to do is get enough money then he can pay everyone to follow his style guidelines and have shot anyone who doesn't.

        DWIM is Perl's answer to Gödel

      I'm not sure why you state a 'tradition' as a reason for not adopting a technology. Traditionally people wrote programs on punch cards, and if that technology was still out you could traditionally lounge around in Bell Labs and have a blast with a traditional language like SNOBOL all night long. Traditions change, get up to do date, gramps.

      Your whole argument revolves around old editors, which I appended to my rant in favor of tabs prior to its submission on perl monks. You brought nothing to the table in your response, and I would like to thank you for so aptly summarizing what the opposition has against tabs

      Evan Carroll
        Tradition becomes defaults, and defaults matter.

        I personally switch between at least 3 different editors, and wind up reading code semi-regularly on at least 5 different machines under a number of accounts, some of them shared. Every one of those editors and machines has a default tab stop of 8, and my life is too short to worry about changing them all.

        With space based indentation, I don't have to care. I also don't have to try to convert everyone around me who uses space based indentation (and some of whose editors are stupidly set to compress code by turning 8 spaces into tabs). All in all it makes life far nicer for me that the codebase I am working on is space indented. (With some tabs whose presence is invisible to me, because I leave the tab width alone.)

        Therefore to me there is a slight advantage to space basd indentation. And there is a huge advantage when it comes to not having to fight the whole world.

        Actually punched cards never used tab characters, they were always space indented, so in that sense I am harking back to tradition - the old ways are the good ways having survived the test of time.

        Actually what I was advocating was not a traditional technology when editors were not smart enough to manage spaces to provide the programmers desired indentation, but the use of modern editors that can manage space based indentation and a whole lot more besides.

        In very large part this whole debate is a storm in a tea cup because editors just don't care whether you use space or tab based indentation. Indeed Komodo takes a look at the document you load and makes a pretty damn good guess at what tab width is most likely to be correct for the document.

        Go ahead, use your anachaic and archaic tabs - my editor can eat them for breakfast and spit out spaces.

        DWIM is Perl's answer to Gödel
Re: Tabs vs Spaces lets give this a go
by ioannis (Monsignor) on Oct 08, 2006 at 06:09 UTC

    The tab character is not a meta-character. It belongs in the group of 'control' characters, the first 32 codes as ASCII, whose historical mission was to control the the output device; as such, the meaning of each control character varies for each device -- for example, a printer will advance the head horizontally, but another device might do something different.

    As for code, I agree with you philosophically; although, the is always the danger when code is passed around for the tab character to transform into either a single space, or into 8-spaces. Spaces are never candidates for transformation, but tabs travel with danger.

      "The tab character is not a meta-character." Sure it is, if you think otherwise you are wrong. A tab character, traditionally as GrandFather would say, is meant to relay information about the distance of your text from the left margin. As he also pointed out, to no end, it is often visually portrayed as 8 spaces. While you point out those 32 codes in ASCII, you should review how many of them are in fact meta characters, which by definition are chracters, thats pertain to relaying information about other "characters." You can find them for own reference at, upon reviewing them you will find a great many of them are indeed :"meta characters."

      Evan Carroll

        Actually, no. ASCII provides control characters which may carry meta-information, at least according to the article that you linked, but clearly didn't understand:

        ASCII reserves the first 32 codes (numbers 031 decimal) for control characters: codes originally intended not to carry printable information, but rather to control devices (such as printers) that make use of ASCII, or to provide meta-information

        Any character can carry meta-information. That depends on the context in which it is used. That doesn't make it a meta character.

        Clearly, according to the reference that you give, you are wrong.

        DWIM is Perl's answer to Gödel
Re: Tabs vs Spaces lets give this a go
by xdg (Monsignor) on Oct 08, 2006 at 09:51 UTC

    Wow. There are so many things wrong with this post that I almost want to consider it to be marked a troll. I'd say someone hacked your account to hurt your XP, but too much energy seems to be put into the post for that. I appreciate that you feel "righteous" but I think your energy is misplaced on this one.

    I'll start out this diatribe by stating... this is the most blatant flaw in the PBP.

    That's almost worth a "--" right there. PBP has a lot of great recommendations, but of the blatantly bad ones, tabs vs spaces can't possibly beat recommending half-a-dozen or so brand new CPAN modules and declaring them "best practice". (With Class::Std being my personal least-favorite among them.)

    tabs as code-metadata

    Metadata should derive from the data -- it shouldn't drive the data. declaring "tabs are better" so that people can search code by indentation level is one of the most bizarre justifications I've ever heard. Code-search should be one of the last considerations for code formatting choices.

    For me -- it comes down to simplicity. Too many things need to go right for tabs to work properly the way you describe. You have to have a smart editor. You have to only use tabs to your indentation level and then you have to use spaces for any alignment after that. That's too easy to get wrong. (Plus you have to think about it.) And everyone you share code with has to get it right as well.


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: Tabs vs Spaces lets give this a go
by chargrill (Parson) on Oct 08, 2006 at 06:09 UTC

    Personally, I don't agree with you. I agree more with TheDamian and Grandfather. Honestly though, I developed the preference for spaces so long ago that I've forgotten exactly why I prefer spaces to tabs.

    However, you present your ideas pretty clearly and logically and made me examine my own thinking on the subject, so I upvoted you.

    And I raised this discussion on IRC, where I think the main idea is this: overall (and not just this particular topic) PBP recommends picking a convention and sticking with it. If you share his preference for spaces, awesome for you. If you prefer tabs, just make sure your whole organization does too. :)

    s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; = qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
      I, too, had forgotton why I had firmly moved into the anti-tab / pro-space division until last week.

      I was given the task to maintain a piece of software. As any good software engineer would do I kept to the original conventions of this software; as much as I don't like tab-indented code I continued to use tab indents to maximise maintainability of this particular piece of code and to minimise the diffs when checking in changes.

      Unfortunately I got my editor to tabify my section of the code (as I use space indent by default). The trouble with that is that it converted a string of 8 spaces "        " into "\t". Lucky for me we had automated tests that flushed this problem out!

      To protect myself against this kind of thing I've kinda resolved personally to encode spaces in strings as "\x20".

      But don't be fooled.. tabifying code is horribly inconsistent and prone to much danger. It's bad.

      "Honestly though, I developed the preference for spaces so long ago that I've forgotten exactly why I prefer spaces to tabs." Great, if thats you preference fine, just realize the only advantage it has over my suggestion is support for legacy features. I think I've elegantly laid out the pros of tabs, take it or leave it.

      Evan Carroll
Re: Tabs vs Spaces lets give it up
by derby (Abbot) on Oct 08, 2006 at 11:29 UTC

    With tools like perltidy why should one care? I've given up on trying to browbeat errant devs about proper style and I just filter code through perltidy.

    My evil master plan is to hook perltidy into our version control system so then I can say - "I'll take a look at your code after you check it in."

Re: Tabs vs Spaces lets give this a go
by talexb (Canon) on Oct 08, 2006 at 09:57 UTC

    Evan, like I said in #perl on IRC a few hours ago, I respect your right to be hard-core, but the way arguments are discussed on Perlmonks is that you respond specifically to each argument, rather than updating the root node. That way, another can follow the various paths of conversation.

    Normally in this tytpe of situation (a controversial suggestion, discussed with reasoned reponses), I upvote the root node for bringing up an interesting discussion and, if absolutely necessary, downvote any replies I violently disagree with, or think are not at all helpful or downright inaccurate to the majority of other readers. But your refusal to follow the usual and customary discussion protocol made me decide a downvote was appropriate.

    And don't worry about XP -- if you're passionate about a subject, just go ahead and write, and let the XP fall where it may.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      point well taken.

        Good job on removing the replies from the root node and reditributing them where they belong. Thanks.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Tabs vs Spaces lets give this a go
by demerphq (Chancellor) on Oct 08, 2006 at 12:15 UTC

    All I know is that the major advantage of tabs is that they reduce source size, beyond that they make a lot of things difficult.

    For instance your editor groks mixed tabs/spaces and interconverts on indent/outdent as appropriate. But my editor either uses a tab or uses some number of spaces, and for reasons unknown decides that the appropriate place to insert its "indent string" is at the front of the line. End result? When I try to outdent your code it doesnt work properly, as 4 spaces + a tab is visually the same thing as a single table when the tab is defined to be 8 chars long. Which it has to be if you are working with code that comes from editors that do the evil tab/space thing.

    I routine encounter this problem, and I routinely mutter about it, as often the perl patch pumpkings convert my space indented code back to tab indented code before the apply the patch, so even my own code mysteriously ends up having fucked indenting properties in my editor when i go to change stuff. Necessitating me to convert the code back to spaces, blah blah.

    Even worse is when you work with people whose idea is to change the size of a tab, which is just a nightmare when people on your team all have different ideas on how big it should be. Inevitably people use spaces instead of tabs _sometimes_ and then you end up with indenting problems.

    So I'd say that in the interest of maximum interoperability and minimum hassle use spaces instead.


Re: Tabs vs Spaces lets give this a go
by tilly (Archbishop) on Oct 08, 2006 at 20:25 UTC
    While I laud your desire to clearly articulate your programming opinions, I must point out that someone who just discovered revision control probably has something left to learn about good programming practice. Therefore when you find yourself on the opposite side of a style debate with most of the programming world, you should seriously consider whether or not this is because the rest of the world knows something that you do not.

    I already stated in Re^3: Tabs vs Spaces lets give this a go why I personally prefer space based indentation over tab based indentation. That answer included several things that you did not address in your post. Including the needs of people who use many machines, shared accounts, and the practicalities of dealing with people who are not already acting in accord with what you want. To me those outweigh the minor advantage of having different programmers who want to view the same code with a different level of indent.

    Particularly since it is my opinion and experience that it is easy for competent programmers to adapt themselves to the locally-popular indentation style. Particularly when they're going to have to adapt themselves to the locally popular brace style anyways. (If there is no consistent locally popular style, then you have bigger problems...)

      That is what is often called an "ad personam" I'll quote wikipedia on this
      "Ad hominem abusive (also called argumentum ad personam) usually and most notoriously involves insulting one's opponent, but can also involve pointing out factual but damning character flaws or actions. The reason that this is fallacious is that usually, anyway insults and even damaging facts simply do not undermine what logical support there might be for one's opponent's arguments or assertions; argumentum ad personam short-circuits these potential arguments from logic in favor of a direct attack on the opponent's authority."
      ... Those of us competent at debate, neglect arguements (and ignore those) that make references as such. Congrats.

      Evan Carroll
        That is not an "ad personam" attack. (Which is, FYI, usually called "ad hominem". In fact it is so widely known under that name that if you call it that, there is no need to quote from a wikipedia article.) Why not? Because I was not making the point to argue that you were wrong. Rather I was making the point to suggest that you might want to reconsider your current attitude. Certainly posts like Re^2: Tabs vs Spaces lets give this a go demonstrate an unwillingness to listen to people who you probably have a lot to learn from. And being unnecessarily snide and insulting is unlikely to win friends or influence people.

        In fact a good example of your snideness is in the post I am responding to where you talk about, "... Those of us competent at debate..." Thereby implying that you're competent at debate, and I'm not. While it is satisfying to get a dig like that in, I suggest that you review my posting history before convincing yourself that I know nothing and am incompetent at debate.

        Furthermore I should point out that when I wish to argue that you're wrong, I'll argue that point directly. In fact I did. I stated that the benefit you seek to derive (let each programmer choose the indentation style they get to see) is minor at best, and there are many costs you didn't address with attempting to push tabs everywhere. I enumerated some of those costs, with direct reference to my personal situation. Based on experience, I find those costs to be far worse than the benefit you seek to derive, therefore I think that space indentation is better.

        If you wish to demonstrate your competence at debate, a good place to start would be addressing the points that I made. In other words review the costs that I point out, and explain why those costs are smaller than I think they are, and the benefit you're seeking is bigger than I think it is. This would actually address the substance of my posts much more effectively than jumping up and down and claiming that I'm issuing an ad personam attack.

        I'm sure tilly can defend himself, but I just want to chime in to say you don't understand the meaning of calling an "ad hominem" a fallacy, some clown at Wikipedia notwithstanding.

        "You can't be right because you're a pompous ass who doesn't know his place," is an ad hominem argument, and not to be taken seriously. I happen to think your attitude is extremely annoying, and I can tell that I would not presently hire you for any job that required you to work with a team. But you might still be right about some things. Tying irrelevant character traits to the validity of your arguments would indeed be ad hominem.

        As for the grandparent node, the point is that you have demonstrated that you don't have experience, and that happens in fact to be relevant to your power to make judgment calls. You plainly don't think so, but that's just too damned bad. Everyone else in the world (probably you, too) make judgments about how seriously to take other people's judgments on the basis of factors they deem relevant. The relevant issue here is that you are not likely a veteran programmer, so pointing that out is simply not a "fallacy." In addition to your evident inexperience, your omission of meaningful consideration of the alternative position in your so-called "argument" is another bright red flag, marking you as "what is often called," to use your insufferable phrase, a "blowhard." HAND.


        Oh. You're one of those people who cry "Ad hominem". Which implies that you think your audience is too stupid to notice.

        Your arguments must be worthless.

        You misspelled argument. Again.
Re: Tabs vs Spaces lets give this a go
by jbert (Priest) on Oct 08, 2006 at 14:11 UTC
    A consequence of your first two points:
    1. Tabs belong in one place in a document; and that place only. That place is in between the left-margin and the first word character. This is the tab-zone.
    2. Nothing other than tabs, belong in this tab-zone
    is that you can't do any vertically-aligned code. For example, if you want to split a long while- or if-condition onto multiple lines, you can't align things for readability in such a way which is tab-width agnostic.

    So, I would disagree with your point 3. Not every line of code has an explicit indentation level, in particular continuation lines do not.

    I prefer space indentation for these reasons.

    A counter argument could be made that such long lines are always bad, or that one should use a sufficiently wide line and so that line-splitting is never necessary. But you'd need to establish that point before having a tab-v-space argument, since the 'pro tab' position depends on it, I think.

      Generally, what he means is to "tab" until you get to the indentation level for an ordinary line at that point, then use spaces after that for justifying continuation lines. E.g.:

      # "--->" is a tab and "." is a space: --->{ --->--->if ( really_long_condition_here() && --->--->.....another_really_long_condition_here() ) # see spaces on t +his line --->--->{ --->--->---># do stuff here --->--->} --->}

      That way, you can adjust the tab display size, but the alignment is preserved.

      I personally can't stand it, but that's the approach the tab-advocates suggest.


      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        I advocate *NO* spaces between the left margin and the first word character

        I personally would never have a space char inbetween the left margin and 'another', so no that doesn't adhere to the style specified at all. Nor, in an ideal world should that require double spaces at all; as it should be abundantly obvious to any editor where it can wrap that and the user should configure this presentational element in their editor.

        As for me, I would probably type that out as:

        --->--->if ( --->--->--->really_long_condition_here() --->--->--->&& another_really_long_condition_here() --->--->) { --->--->---># do stuff here --->--->} --->}

        Evan Carroll

      I've given a code example in the thread below this for examination. And, just to summarize you are arguing that static/absolutely specifying presentation within data is a good thing?

      Now about that to which you were arguing, please point out how storing the linear distance, ( an ammount of "\t" which the viewer can render as it chooses) hinders the alignment in any fashion?

      Evan Carroll
        Thanks for the code sample.

        I think it violates your intention of tab-as-meta-character-carrying information. Unless you consider the contents of the if() conditional to be one-level-nested to the if, you've lost the accuracy of your meta-data.

        And if you find yourself starting to think that "well, in some sense the contents of the if-conditional is at a nesting level deeper than the if" I would conclude:

        1. You would need to be consistent and hence indent the conditional within every if-and-while-and-etc in the same way.
        2. That you're sticking to the point for the sake of it, since this to me is a reductio ad absurdum.
        In summary - I think we've established that the number of tabs can't be consistently used as meta data for the nesting depth. Given that, the only purpose is presentational, and this is better served using spaces, as is evidenced (in my opinion) by the code sample you gave.

        Formatting of code as text is done for presentational reasons (i.e. to look nice to humans). There are good reasons for doing this, since done well, code formatting increases legibility and ease of comprehension, hence reducing bugs etc.

        As to whether presentation within data is a good thing or not in general, it depends. If the tools don't care either way and a human might see it, then why not? I note in passing that network protocols and data formats with easy-to-read text formats generally out-compete those with binary formats which require tools to reformat for humans (e.g. XML/ASN.1, SMTP/X.400, etc)

        A web site which spits out an HTML page without any (useless except for presentation) newlines is harder for humans to examine, learn from, play with and fix when broken.

Re: Tabs vs Spaces lets give this a go
by mreece (Friar) on Oct 08, 2006 at 07:03 UTC
    what really drives me nuts is editors that like to write 4 spaces for one indent, tab character for two.

    the more general problem with tabs is that someone invariably is going to want to indent a wrapped line an additional 6 spaces and is going to do it with a tab and two spaces, and someone else is going to try to display tabs as 3 spaces and it won't line up.

    it may not technically even violate your rules above (tho 5 is ambiguous enough it may apply).

    you've also taken away the ability to use the tab key to speed the alignment of tabular arrays.

    to say, i agree in principle, but not in practice. the easiest way to get consistency is to restrict freedom -- soft tabs only, 4 spaces per indent.

      So then your arguement is based on the presupposition that

      1. Terminal widths really matter, and 80characters is such a die hard rule everyone must unconditionally follow it.
      2. Terminal widths should include the indentation - has other implications as well, reference the analogy to code searches
      3. That it is easier to set a standard on the amount of spaces than it is a standard on the visual representation of an indent
      Myself, personally, I think that you are wrong on every point. I believe only word characters should count towards your arbitrary horizontal width. And if text-editors must hold true to 80 visual characters, or 78characters of width, then these editors should be free to display a tab differently or more intelligently wrap lines. The possibilities for a display of depth are damn near infinite, and there is no reason to stringently stick to an exaggerated amount of spaces at all.

      Evan Carroll
        perhaps i was unclear; i did not mean to suggest anything about terminal widths (i usually use 130), only about visual alignment with respect to voluntary hard-wraps, such as tabular ternaries and the like.

        personally i think column/character position is a rather useless feature of code searches, but even so, i would expect it to report one character per character aka the column number, which is what i get and expect with spaces.

        i'll go back to encouraging tabs only when we our editors support smart tabs that work for arbitrary and automatic spacial alignment (not just indent level), with proprtional fonts as a bonus.

        Do you think you are going to trick us by posting responses with big words like "presupposition" and bulleted lists? We can see through your "arguments." You are a troll with half a clue. You may be useful when you grow up a little bit, but for the time being, you are not.

        And yes, this is an ad hominem, but I don't really think you're trying to make a sound logical argument to begin with. As the saying goes, never try to have a rational argument with an irrational man. You're not rational -- you're a troll, and it's annoying.

Re: Tabs vs Spaces lets give this a go
by halley (Prior) on Oct 09, 2006 at 15:04 UTC

    It's just a rite of passage that a newcomer to the field of computer programming must explore. In your words, "let's be blunt now."

    • argue their unflagging, nee unflinching support for one side of a useless style standards discussion
    • loudly expouse the virtues of their own code editor over all others, of which maybe a third of the useful features have been explored adequately
    • rally for the adoption of an obvious workflow advantage such as using centralized source code repositories
    • create and standardize on a new and smarter "string" class which only serves as a standard for one project

    For me, if I have to use an editor which makes me even THINK about tabs versus spaces, I feel like a caveman eating mammoth meat off the bone. A good editor will just adapt for you, and adjust the indentation to each likely point of visual indentation for you, and save it with the appropriate encoding automatically. That's all it is: an application-specific encoding of whitespace, and therefore, an almost entirely uninteresting implementation detail.

    And for that one guy who advocated them for the purposes of reduced file size, please go buy another 10MB winchester or bernoulli box down at Radio Shack before you tear the 1983 calendar off your wall.

    Thanks for separating out the responses. It gave more voting exposure.

    [ e d @ h a l l e y . c c ]

Re: Tabs vs Spaces lets give this a go
by zentara (Archbishop) on Oct 08, 2006 at 12:46 UTC
    What are you trying to do, turn Perl into Python? Those f**king tabs are what turned me off to Python right from the start.

    I upvoted you though, for having the guts to speak your dangerous thoughts. :-)

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: Tabs vs Spaces lets give this a go
by shmem (Chancellor) on Oct 08, 2006 at 12:26 UTC
    You are only as good as your tools, "\t" is one that shouldn't be neglected.
    You might be right on all your arguments (solomonically spoken), here you are wrong. A "\t" isn't a tool, it's material, if anything. I use it a lot in regular expressions ;-)

    Tabs, spaces, whatever - having an editor which DTRT (and that's even vi on good ol' SunOS4, though not on early HPUXen) I simply adapt to what style's at hand. Just keep yourself flexible and focus on the real problems in life ;-)

    BTW - I never ever try to impose my personal preferences on others, be that by ways of persuasion, argument, or force.


    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Tabs vs Spaces lets give this a go
by hossman (Prior) on Oct 08, 2006 at 08:45 UTC

    Those who are interested in this topic may want to consider Elastic Tabstops (which seems to be esentially what EvenCarrol is argueing for, allthough i'm not entirely sure since I did not consider his arguments carefully because I am not one of the people interested in this Holy War)

Re: Tabs vs Spaces lets give this a go
by Hue-Bond (Priest) on Oct 08, 2006 at 09:13 UTC
    So as not to have to withstand the brunt of multiple downvotes from the same people, I have added responses in the main thread

    Then you are going to get downvotes from other people (me, for example). Replying in your main node will make it difficult for everyone to follow the conversation and, which is worse, to contribute to it. If you want to avoid being downvoted, there are better ways to do it, like posting as anonymonk (not that I'm recommending it) (Update: OP removed the replies and posted additional nodes so this no longer applies).

    FWIW, I use tabs yet. I plan to switch to spaces Real Soon Now.

    David Serrano

Re: Tabs vs Spaces lets give this a go
by radiantmatrix (Parson) on Oct 13, 2006 at 15:53 UTC

    God, I hate this stupid war. Especially when it comes to Perl, if for no other reason than the existence of Perl::Tidy makes conforming to either choice a simple matter.

    Or, as the OP says:

    everyone with a decent modern editor can have their cake and eat it too.

    Every reasonably modern editor can look at code written in either a space-indent style or a tab-indent style and present it in a sensible way. The only thing that really matters is that you preserve the existing style of code you edit to make for readable diffs. And with modern editors and perltidy, this is a very simple exercise.

    (I admit, I have a preference for tabs: it's based on my own personal pedantry that when I press tab, damnit, I want a tab and not an interpolated set of spaces. But I clearly don't possess enough hubris, as I will simply use whatever style the code I'm working on embodies.)

    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: Tabs vs Spaces lets give this a go
by CountZero (Bishop) on Oct 08, 2006 at 16:49 UTC
    Just use a modern code-editor (such as Komodo) which can tabify or untabify your code at will and does a great job of aligning your opening and closing brackets in such a way that you get very neatly looking code irrespective of using tabs or spaces.

    To me this discussion lokoslooks to be of the "what is the sex of an angel" kind.


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: Tabs vs Spaces lets give this a go
by pdcawley (Hermit) on Oct 10, 2006 at 10:03 UTC

    In the case of an unwanted pregnancy, there's a three way choice: abort; keep the baby; give it up for adoption.

    All the choices are wrong, which makes choosing the least wrong one in your particular circumstances very hard indeed.

    Choosing your code indentation style is unlikely to have such a devastating effect on the lives of at least two people, but there's a strong case for saying that all the available choices are wrong as well.

    The best choice to make is the one your teammates (or your team leads) make. If you have the tools to let you code in your favoured style and then convert back to house style, good for you. If you don't, you live with house style.

    So, I have a preference certainly (spaces throughout), but it's not The Right Answer. Nothing is.

    Arguing that your way is the One True Way is already laughably futile. Arguing that it's the One True Way because it adds valuable extra metadata, when that 'metadata' can be worked out by any code editor worth its salt (or delegated to perltidy) would appear to plumb the very depths of futility. Well done.

    Someone give that man a bathyscaphe.

Re: Tabs vs Spaces lets give this a go
by monarch (Priest) on Oct 08, 2006 at 22:45 UTC
    My feeling is that code is not meta data, rather it is a work of art in some respects. Whilst a compiler doesn't see it that way (code is code) a human, on the other hand, demands presentability, readability, maintainability. A human has to diff the code, has to have comments, and has to abide by coding conventions in a work place in order to make collaboration on a project easier. These things are not meta in any way!

    A programmer's canvas is plain old text. Usually monospace. The difference is that a word processor has a different canvas - that canvas has multiple fonts, proportional spacing, and tab stops that align paragraphs.

    By realising that the programmer's canvas and the word processing canvas are two different things we can come to realise that the tab character (\t) is prone to creating more problems than it solves for programmers who are attempting to paint on a canvas that alters shape between user experiences whenever a tab character is involved.

      "\t" doesn't create any problems nor does your post mention any. Again another arguement that defaults to the ineptness of the editor to only display one monospaced font. If you opted to use "\t", you too could move away from a monospaced font, or you can continue to stick with it.

      "\t"s are data, about data, they convey the level of the depth of code, that makes them meta. Code can usually be processed without whitespace, except in langauges like python, where the meta-information is significant to the compiler, and therefor undeniably dual purposed.

      Evan Carroll
        Wait a minute.. did you just say "\t" doesn't create any problems???

        Call me funny, but in computer science, nay engineering, nay life there's always a price to be paid for every decision. Indenting with spaces does cause problems. Indenting with tabs does cause problems. The important thing is to identify the solution that causes the least additional problems.

        In fact, previously in this thread, I posted a very tangible situation in which tabifying caused me much grief.

        On another point: if you think programming in variable-width fonts is a good idea then that's okay with me but clearly you are programming in quite a narrow environment. Experience would teach you that monospace is required in many (of course not all) technical situations.

        The argument that seems to be continually missed by the pro-tab lobby is one of cross-platform, cross-editor maintainability. Say goodbye to maintainability next time you add tabs to your code. You're making diffs harder, forcing individuals to guess "is that whitespace a tab or several spaces" and causing your code to be displayed differently on a number of different environments.

        I could go on and on but really this is something experience has to teach you. The strength with which you are pro-tab has clearly scared some programmers in this thread whose many previous postings on Perlmonks have left me with deep respect.

        Remember, a lot of us have been programming since our earliest teenage years. Yes, one can come out of uni with a computer science degree, but this doesn't make one an experienced programmer. When you've worked in multiple environments, multiple languages, multiple teams, different editors, different OSs, different platforms, different bit widths on processors, different source code repositories, you'll start to appreciate why some of us feel the way we do.

Re: Tabs vs Spaces lets give this a go
by jdporter (Canon) on Oct 09, 2006 at 19:16 UTC

    Clearly, the solution is to use one-space indent.

    Its only downside is that one column of indent can be hard to distinguish readily by eye.

    I'm half serious about this argument.

    We're building the house of the future together.
Re: Tabs vs Spaces lets give this a go
by Anonymous Monk on Oct 09, 2006 at 05:31 UTC

    For all your posturing about good logic, there is something glaring in your post that belies your boasting:

    I admit there is one thing I have neglected. The only fault in this argument is minor and disappearing more every day

    Set up the opposition's argument, and knock it down. It was so easy to knock down, wasn't it? But it's not actually a good representation of the fault in your position. Thus what you have so easily knocked down is actually a straw man. It makes you feel like you've taken care of the opposing case, and looks like that upon casual inspection, but in reality it is a pointless rebuttal indeed. Nice try, pal.

Re: Tabs vs Spaces lets give this a go
by xorl (Deacon) on Oct 09, 2006 at 12:55 UTC
    Interesting. In 10 years of programming, I've never encountered someone who uses spaces to indent code. I'm truly shocked by the number of people here who use spaces.

    I've not taken many CS clasess, just one here and there as required by work (and none at the same college). All of them wanted the code indented and wanted tabs used.

    To me tabs offer 3 things that spaces don't:

    1) smaller file size

    2) easy to change the with in the editior by just changing the location of the tabstops.

    3) who the heck is going to want to count out 16 or 32 spaces when you can just hit tab 2 or 4 times?

    Thoses are my reasons. I'm sure other people will have other reasons.

    The more interesting thing about this thread is the strong feeling it seems to have evoked. I really don't understand it. If your shop uses spaces, use spaces. If it uses tabs, then use tabs. If you're lucky and work in a small one man shop, then use whatever the heck you want or maybe don't even indent. This shouldn't be such a big deal.

    Let's all take a deep breath and count to 100 before anyone makes another post.

      1) Smaller file size is a negligible advantage nowadays IMO. 2) Yep, that's usually true. 3) Surely you are joking! Any half-decent text editor that lets you choose spaces for indentation will use the tab *key* for indentation, but producing the right amount of space *characters* on the file. It will also support autoindent, and maybe even "smart" autoindent (although I personally hate the latter).

      In my experience, although the argument for tabs is pretty logical, it doesn't work that well in practice. Years ago I thought a lot about the issue, decided to use tabs, and configured my system accordingly. It ended up being a lot of trouble whenever I interacted with anyone else or got source code from anywhere else. Even without interacting with other people's code, I had trouble because I was using a variety of programs on a variety of platforms, and not all of them let you configure the tab stops (or it wasn't worth the time). I switched to spaces and I've been much happier ever since. :-)

Re: Tabs vs Spaces lets give this a go
by Anonymous Monk on Oct 08, 2006 at 20:59 UTC
    The people that argue in favor of spaces based on which editor they use are probably also the ones that bemoan the difference in javascript implementations because they can't just stick with browser that most people use. A good editor makes it so you don't care if they are spaces or tabs. Do you decide how to do things, or do you lt your tools do it for you? Who's the one with the brain? You or the editor?
      "A good editor makes it so you don't care if they are spaces or tabs."
      And a good developer DOES care because he knows he and his fellow supereditor might not be the only ones working with that file :)

      Ordinary morality is for ordinary people. -- Aleister Crowley
Re: Tabs vs Spaces lets give this a go
by friedo (Prior) on Oct 08, 2006 at 06:09 UTC
    The OP is so blatantly incorrect that it defies description. Tabs are useless, and if I had my way, the tab button would be pried loose from every keyboard in the world and hurled into the firey depths of a giant volcano.

      Actually the tab key I use all the time - generally it translates to "indent this line the appropriate amount". The tab character should be bannished as you suggest, except perhaps as a separator in csv files.

      DWIM is Perl's answer to Gödel
        Agree. I need the tab key to type two or more spaces (depending on things I edit, perl gets 4, ordinary text gets 2, html gets 1) by one stroke. Well, at least in vim. It also allows me, at the same time, to enter insert mode from normal mode. Yes, I could remap, but I use the key for nothing else. Oh, I'm used to cycle those windows with Alt-Tab. It's really nice to have this in X.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://576936]
Approved by planetscape
Front-paged by brian_d_foy
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2018-07-17 21:44 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (378 votes). Check out past polls.