Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 13 submissions in the queue.
posted by n1 on Sunday June 18, @12:22AM   Printer-friendly
from the not-your-bar-tab dept.

Submitted via IRC for TheMightyBuzzard

The annual Stack Overflow developer surveys often include lots of bad news. "People still use PHP," for example, is a recurring and distressing theme. "Perl exists" is another.

But never before has the survey revealed something as devastatingly terrible as the 2017 survey. Using PHP and Perl are matters of taste. Extremely masochistic taste, certainly, but nobody is wrong for using those languages; it's just the programming equivalent of enjoying Adam Sandler movies. But the 2017 survey goes beyond taste; it goes into deep philosophical questions of right and wrong, and it turns out that being wrong pays more than being right.

Developers who use tabs to indent their code, developers who fight for truth and justice and all that is good in the world, those developers have a median salary of $43,750.

But developers who use spaces to indent their code, developers who side with evil and probably spend all day kicking kittens and punching puppies? Their median salary is $59,140.

Source: ArsTechnica


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough

Mark All as Read

Mark All as Unread

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1) 2
  • (Score: 1, Insightful) by Anonymous Coward on Sunday June 18, @12:29AM

    by Anonymous Coward on Sunday June 18, @12:29AM (#527219)

    I use sublime to convert all tabs to spaces because when I paste it into other places the tabs sometimes mess up formatting.

  • (Score: 3, Funny) by t-3 on Sunday June 18, @12:32AM (1 child)

    by t-3 (4907) on Sunday June 18, @12:32AM (#527220) Journal

    I press tab, and spaces come out.. Where's my 15k?

    • (Score: 0) by Anonymous Coward on Sunday June 18, @09:19AM

      by Anonymous Coward on Sunday June 18, @09:19AM (#527407)

      You should probably consider including :set expandtab

  • (Score: 2) by takyon on Sunday June 18, @12:34AM (4 children)

    by takyon (881) <{takyon} {at} {soylentnews.org}> on Sunday June 18, @12:34AM (#527222) Journal

    Does anybody hit the spacebar four times to get their carpalio? What about single space indentations?

    As the first AC noted, converting tabs to spaces can be necessary.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 2) by The Mighty Buzzard on Sunday June 18, @12:46AM (1 child)

      Only until you've slit the throats of all the space-using bastards. Then sanity can return.

      --
      Save Ferris!
      • (Score: 2) by Lagg on Sunday June 18, @01:25AM

        by Lagg (105) Subscriber Badge on Sunday June 18, @01:25AM (#527246) Homepage Journal

        ╭ರ_•

        I say, calling the space users bastards when it's between the tab using swine and the hipster combo method.

        --
        http://lagg.me [lagg.me] 🗿
        8DF5 7CC6 9572 2282 4BD7 CC2C 1316 E8D2 AB04 0CBD
    • (Score: 2) by frojack on Sunday June 18, @01:32AM

      by frojack (1554) Subscriber Badge on Sunday June 18, @01:32AM (#527253) Journal

      We wrote our own code reformatter decades ago to do that work. We can slap in paragraphs of code, reformat it with one click and its clean. The Tab expansion and compression is turned off in all of our editors. When customers send us code samples, we don't even look at it till we reformat it. The reformat often makes rookie mistakes stand out.

      --
      No, you are mistaken. I've always had this sig.
    • (Score: 2) by KritonK on Monday June 19, @09:58AM

      by KritonK (465) on Monday June 19, @09:58AM (#527829)

      :set sw=2

      I hit the spacebar only two times!

      When I first learned about indentation, I didn't like how ugly 8-space indentation, created using the tab key, looked. Then I saw someone use two spaces for indentation, liked what I saw, and have been using it ever since.

      I remember reading an old paper, possibly in Software Practice and Experience, where they had studied the readability of programs as a function of the size of the indentation. They concluded that programs are most readable when 2 to 4 spaces are used for each level of indentation. From personal experience, I can only agree with this. One space is way too little for the indentation to be discernible, while 8 spaces move the interesting bits of complex code way to the right, making them hard to understand.

  • (Score: 2) by Snotnose on Sunday June 18, @12:47AM (83 children)

    by Snotnose (1623) on Sunday June 18, @12:47AM (#527227)

    Up until '04 or so I used tabs and didn't see why anyone would care. Then I got put on a Python project. Holy bejeebus did tabs vs spaces fuck everything up. 4 developers, some used tabs, some spaces, and the tabstops were 2 or 4 spaces. Fucking nightmare.

    That's when I found vim's expand tabs feature, at least other's could look at my code and know the indenting. At least, until they changed my code.

    I love Python. I fucking hate the use of whitespace to delineate code blocks. Especially when weak management can't get developers to agree on 2, 3, 4, 8 spaces per tab.

    • (Score: 4, Insightful) by Whoever on Sunday June 18, @12:55AM (76 children)

      by Whoever (4524) on Sunday June 18, @12:55AM (#527232)

      And if everyone used tabs, all of those problems would go away.

      People could set the way tabs are displayed: equivalent to 2, 3 or 4 spaces.

      Is there actually a good reason to use spaces, other than "other people do it" and the non-reason "my editor does this automatically".

      The last "reason" is merely a claim that they have a method to work around a bad approach.

      • (Score: 3, Insightful) by KGIII on Sunday June 18, @01:11AM (15 children)

        by KGIII (5261) on Sunday June 18, @01:11AM (#527240) Journal

        Consistent display when sharing code on large projects.

        --
        "So long and thanks for all the fish."
        • (Score: 5, Touché) by The Mighty Buzzard on Sunday June 18, @01:24AM (5 children)

          Consistent display? Oh, you mean whitespace fascism. Might as well store your source in .pdf format.

          --
          Save Ferris!
          • (Score: 1, Funny) by Anonymous Coward on Sunday June 18, @01:39AM (3 children)

            by Anonymous Coward on Sunday June 18, @01:39AM (#527259)

            I store my source in a docx file, you insensitive clod...

            • (Score: 2) by Azuma Hazuki on Sunday June 18, @02:06AM

              by Azuma Hazuki (5086) on Sunday June 18, @02:06AM (#527272)

              I modded you funny, but that is some seriously dark humor. Not even the COBOL heads would do that...

            • (Score: 0) by Anonymous Coward on Sunday June 18, @05:16AM (1 child)

              by Anonymous Coward on Sunday June 18, @05:16AM (#527344)

              My former room-mate claimed the bank Credit Union she worked for did just that.

              Though her title was "systems analyst" rather than programmer.

              She did not last long after pointing out it was easier to edit the raw document mark-up in wordpad.

              • (Score: 1, Touché) by Anonymous Coward on Sunday June 18, @02:55PM

                by Anonymous Coward on Sunday June 18, @02:55PM (#527474)

                Instead of entering tabs you can code in an excel document and indent by starting a line one cell to the right.

          • (Score: 3, Funny) by KGIII on Sunday June 18, @01:59AM

            by KGIII (5261) on Sunday June 18, @01:59AM (#527267) Journal

            Well, now we see why you're paid less. Sheesh.

            --
            "So long and thanks for all the fish."
        • (Score: 1) by Arik on Sunday June 18, @02:33AM (7 children)

          by Arik (4543) on Sunday June 18, @02:33AM (#527284)
          "Consistent display" comes at a high price and gives nothing of value in exchange.
          --
          "Unix? These savages aren't even circumcised!"
          • (Score: 2) by KGIII on Sunday June 18, @03:03AM (5 children)

            by KGIII (5261) on Sunday June 18, @03:03AM (#527293) Journal

            Uniformity has many benefits. It does, of course, depend on the standard. Consistency has been a great way to improve many things. Even the web has many standards, and some level of consistency - at least behind the scenes.

            It's also pretty easy to change tabs to spaces with pretty much every editor and IDE. I'm not seeing how this is a lot of extra effort.

            Personally, I don't care if it is tabs or spaces, so long as it is consistent for the project. However, if they mix them both together, I'd be hard pressed to pass down a guilty verdict for murder, if I were on the jury. If they mix them both in the same file, I would find that justifiable homicide.

            --
            "So long and thanks for all the fish."
            • (Score: 2) by Arik on Sunday June 18, @03:32AM (4 children)

              by Arik (4543) on Sunday June 18, @03:32AM (#527307)
              "Uniformity has many benefits. It does, of course, depend on the standard. Consistency has been a great way to improve many things. Even the web has many standards, and some level of consistency - at least behind the scenes."

              Whoosh. Didn't criticize consistency. Criticized 'consistent display.'

              Consistency is very important - at the right level.

              Consistent display is simply not the right level.

              "It's also pretty easy to change tabs to spaces with pretty much every editor and IDE. I'm not seeing how this is a lot of extra effort."

              Who said it was a lot of extra effort?

              "Personally, I don't care if it is tabs or spaces, so long as it is consistent for the project."

              Imagine applying the same logic to, oh, building houses.

              "Personally I don't care if you use the right material for those load-bearing columns or not, just as long as they all look the same."

              --
              "Unix? These savages aren't even circumcised!"
              • (Score: 2) by KGIII on Sunday June 18, @04:28AM (3 children)

                by KGIII (5261) on Sunday June 18, @04:28AM (#527327) Journal

                In order...

                Consistent display is the benefit of consistency.

                You're free to disagree with that being the right level. If you can't understand the benefits, I'm pretty sure I can't reason you away from that position. Have fun making less money.

                There are many places look exactly the same. They were built to the same plan. Why? It is more efficient.

                To use your attempt at a false equivalency, you're the construction worker and not the home owner.

                If you don't understand the benefits of a consistent display, I'm not sure what to tell you. It's easier to work with, it's easier to collaborate, it can facilitate greater quality, it is more efficient, etc...

                Consistency has enabled a great deal of modernity.

                --
                "So long and thanks for all the fish."
                • (Score: 2) by Arik on Sunday June 18, @04:52AM (2 children)

                  by Arik (4543) on Sunday June 18, @04:52AM (#527336)
                  Uniformity of display, cosmetic uniformity, is neither necessary nor sufficient to give the benefits you claim. Those benefits come from interoperability, which is an entirely different thing. Cargo cult thinking.
                  --
                  "Unix? These savages aren't even circumcised!"
                  • (Score: 2) by KGIII on Sunday June 18, @05:18AM (1 child)

                    by KGIII (5261) on Sunday June 18, @05:18AM (#527347) Journal

                    LOL

                    Are you the person up-thread, who uses comic sans and writes code in Word?

                    --
                    "So long and thanks for all the fish."
                    • (Score: 0) by Anonymous Coward on Sunday June 18, @12:05PM

                      by Anonymous Coward on Sunday June 18, @12:05PM (#527432)

                      Do your coding standards also enforce a specific font face and text size for your code, and dictate the code highlighting colors to use? Enforcing those would provide a more consistent presentation, right?

          • (Score: 0) by Anonymous Coward on Monday June 19, @08:28PM

            by Anonymous Coward on Monday June 19, @08:28PM (#528129)

            I don't know if you're using spaces or tabs, but whichever one it is seriously mangled your font.

        • (Score: 0) by Anonymous Coward on Sunday June 18, @03:36PM

          by Anonymous Coward on Sunday June 18, @03:36PM (#527490)
          And how do you get consistent display on large projects if you don't force everyone to use the same monitor and device among other things?

          I might want different indentation size on my phone compared to my 8K monitor or my AR display.

          Everyone using actual tabs allows the source to have the same meaning while having different viewing indentation, even for stuff like Python.
      • (Score: 2) by Snotnose on Sunday June 18, @01:14AM

        by Snotnose (1623) on Sunday June 18, @01:14AM (#527241)

        No, if everyone used expand tabs things would be groovy. Then it doesn't matter if your tabstops are 2, 3, 4, 8, 92, whatever. Tabs turn into spaces which lets your co-workers can easily figure out your program flow.

        Tabs are evil if management doesn't specify tabstops. If management does specify tabstops then tabs are bad.

      • (Score: 0) by Anonymous Coward on Sunday June 18, @01:17AM (34 children)

        by Anonymous Coward on Sunday June 18, @01:17AM (#527243)

        You mean if everyone used spaces the problems go away.
        SPACES ALWAYS WORK. Don't be a dick. USE WHAT ALWAYS WORKS.

        • (Score: 2) by The Mighty Buzzard on Sunday June 18, @01:26AM (33 children)

          Tabs always work. It doesn't make a fuck if your editor displays them as 2/3/4/8/1337 spaces, as long as it does so consistently.

          --
          Save Ferris!
          • (Score: 2) by vux984 on Sunday June 18, @01:58AM (25 children)

            by vux984 (5045) on Sunday June 18, @01:58AM (#527265)

            It doesn't make a fuck if your editor displays them as 2/3/4/8/1337 spaces, as long as it does so consistently.

            If a document has a mix of tabs and spaces, for any reason. It can look fine on one system, and get completely screwed up on another system with a different tab size, which will expand the lines with tabs differently than the lines with spaces, or heaven forbid... lines with some tabs and some spaces.

            Now of course, "this should never happen", but it absolutely will, especially with multiple developers using multiple editors ... and since it is whitespace it all looks the same; so unless you go out of your way to specifically look, you won't see any issue until it pukes all over itself somewhere on someones system.

            Tabs always work.

            Only, as long as you *only* use tabs, which is a big assumption.

            • (Score: 0) by Anonymous Coward on Sunday June 18, @02:20AM

              by Anonymous Coward on Sunday June 18, @02:20AM (#527279)

              I've worked with people who code in Word. Yes.

              Or in their editor of choice they use non-fixed width typefaces (like Comic Sans). And so they do all sorts of crap in their editor-of-choice to make their work look "right" to them, and it blows up in everyone else's editors.

              Reminds me of the old days when visual editors (aka Word) were becoming mainstream for most people. People were used to forcing layout with tabs, spaces and manually entered line breaks, in apps like WordPerfect. They'd then use Word to look at their WP docs, and wonder why they looked like shit, especially if they needed to change anything with their current fonts.

              Still to this day most people using Word, etc. have the same problems, er, still work the same frikkin' way.

            • (Score: 4, Informative) by Arik on Sunday June 18, @02:27AM (17 children)

              by Arik (4543) on Sunday June 18, @02:27AM (#527283)
              "If a document has a mix of tabs and spaces, for any reason. It can look fine on one system, and get completely screwed up on another system with a different tab size, which will expand the lines with tabs differently than the lines with spaces, or heaven forbid... lines with some tabs and some spaces."

              You're making a deep conceptual error here - you're thinking of a tab as being identical to the 2 or 4 spaces or whatever that a particular system chooses to use to display them on your screen. They are not. (And if your editor really represents them with nothing more than a certain number of spaces, it's broken, but more on that below.)

              "Now of course, "this should never happen", but it absolutely will, especially with multiple developers using multiple editors ... and since it is whitespace it all looks the same"

              Again, what really matters is not what it looks like (that's an ephemeral quality of the interaction between the character and the particular system you're using to view it) but what it actually is. But even further "whitespace it all looks the same" is either a factual error or an indication your system is broken. Tabs and spaces do NOT look the same, not in any decent editor.

              And they simply are are not the same thing. Spaces separate words. Tabs indent larger blocks of text. Using a number of spaces to simulate a tab is cargo-cult behavior, it's copying the visible form of something with no understanding.

              --
              "Unix? These savages aren't even circumcised!"
              • (Score: 0) by Anonymous Coward on Sunday June 18, @05:02AM

                by Anonymous Coward on Sunday June 18, @05:02AM (#527341)

                it's copying the visible form of something with no understanding.
                Tab is a control key. It is a left over from teletype. On the original typewriters where you would pound out a tab it would put out 4/8 spaces (or configurable using tab stops). There was no special char there just a carriage movement. It was space on the original medium. There was no difference. Then came along the teletypes and their special key codes for it. Some fool thought it was a good idea to put the control code in a text file. When you have a choice of two things people will inevitably pick both.

                I personally do not care *which* one you pick. Just be consistent. Do not mix them. If you do 4 spaces then use 4 spaces everywhere, or tabs everywhere. Just be consistent. That is all I ask. Especially if you are in python.

                My projects all use spaces as tabs have had a bad habit of braking compilers for me. 4 different ways of chasing my time in what ended up being a tab instead of a space. That is just me protecting myself against wasted time.

              • (Score: 2) by vux984 on Sunday June 18, @07:36AM (15 children)

                by vux984 (5045) on Sunday June 18, @07:36AM (#527393)

                Oh come of it. There is no deep conceptual error.

                Tabs and spaces do NOT look the same, not in any decent editor.

                They look the same in pretty much all decent editors. sublime, visual studio, notepad++, atom, vim...

                Again, what really matters is not what it looks like but what it actually is.

                I care how it behaves. And that's a function of the editor. A decent editor can emulate tabs using spaces. Backspace will delete spaces to the tabstop. Tab will add spaces to the tabstop. Works fine.

                Actually storing [tab] control characters in the document results in all kinds of portability issues. Why invite that needless hassle. Its not cargo cult behaviour, its rational expediency. We do it because it *actually* works not because it *looks* likes it works. Using tabs as spaces in a decent editor works better than actual tabs thanks to the elimination of portability issues.

                • (Score: 3, Informative) by Arik on Sunday June 18, @07:59AM (13 children)

                  by Arik (4543) on Sunday June 18, @07:59AM (#527396)
                  "They look the same in pretty much all decent editors. sublime, visual studio, notepad++, atom, vim..."

                  I can't comment on the ones I don't use, but notepad++ shows tabs, they look almost like this:

                  --->That was a tab.
                  --->--->That was two of the buggers.

                  But they're in a different color so distinguishable from actually doing that in text. Pretty neat.

                  With VIM you have choices! Many. Set list is a simple and straightforward way to choose options here, or you can save time and just install https://github.com/Yggdroot/indentLine

                  But again, what's important is not what they look like, but what they are. A space separates words. A tab lines up columns. Calling them 'whitespace' doesn't make them the same thing. A series of LFs (or EOFs) is also 'whitespace' but that doesn't mean you can substitute them for space, or tabs, or vice versa.

                  --
                  "Unix? These savages aren't even circumcised!"
                  • (Score: 2) by vux984 on Sunday June 18, @04:27PM (12 children)

                    by vux984 (5045) on Sunday June 18, @04:27PM (#527513)

                    I can't comment on the ones I don't use, but notepad++ shows tabs, they look almost like this:

                    A quick skim through google images of notepad++ screenshots suggests almost nobody has that option on. I certainly don't dispute that notepad++ and other editors can do it; I've used that capability myself; but I don't have it on most of the time, and evidently most other people don't either. So most of the time, for most people, they look the same.

                    But again, what's important is not what they look like, but what they are.

                    Important to who? The compiler doesn't care. You care. I don't. I care how the keys behave; and I usually use editors that are smart enough to emulate tab behavior with spaces. As often as not, after editing some code, I'll just use the editors own reformat to clean up the indentation and make it format pretty. Except for python (and brainfuck) formatting is for the programmer, and it doesn't matter in the slightest whether tabs or spaces are being used 'behind the scenes'. However spaces are a lot more portable.

                    A space separates words. A tab lines up columns.

                    You might care, but few interpreters or compilers care.

                    Calling them 'whitespace' doesn't make them the same thing.

                    For most languages, they absolutely are the same thing to the interpreter and compiler. Unless they're inside quotes, of course.

                    A series of LFs (or EOFs) is also 'whitespace' but that doesn't mean you can substitute them for space, or tabs, or vice versa.

                    a =
                          b +
                          c;

                    callfunc(
                        a,
                        b,
                        c,
                        d
                    );

                    Both compile just fine in most languages.

                    As for EOFs they aren't defined as "whitespace" in any common language. For example:

                    isspace()
                            checks for white-space characters. In the "C" and "POSIX" locales, these are: space, form-feed ('\f'), newline ('\n'), carriage return ('\r'), horizontal tab ('\t'), and vertical tab ('\v').

                    https://linux.die.net/man/3/isspace [die.net]

                    • (Score: 2) by Arik on Sunday June 18, @06:17PM (11 children)

                      by Arik (4543) on Sunday June 18, @06:17PM (#527546)
                      "A quick skim through google images of notepad++ screenshots suggests almost nobody has that option on."

                      If nearly everyone was jumping off a cliff would you jump too?

                      "Except for python (and brainfuck) formatting is for the programmer, and it doesn't matter in the slightest whether tabs or spaces are being used 'behind the scenes'. However spaces are a lot more portable."

                      And just exactly how are tabs supposedly less portable? Has there ever been a text encoding that didn't include them?

                      "As for EOFs "

                      My bad, I meant FFs, and yes, they are "white space." But again, "white space" is not an essential feature of the text, it's a superficial description based on how you've chosen to setup your editor. In the text, these things are all distinct, and if your editor doesn't show them distinctly, well whose fault is that exactly?

                      --
                      "Unix? These savages aren't even circumcised!"
                      • (Score: 2) by vux984 on Monday June 19, @06:01AM (10 children)

                        by vux984 (5045) on Monday June 19, @06:01AM (#527759)

                        If nearly everyone was jumping off a cliff would you jump too?

                        If someone told me nobody ever jumped off cliffs, looking around and seeing that people were jumping off cliffs all over the place would serve as a rebuttal. You claimed tabs and spaces "looked different". While its true they CAN look different, observationally, very few people use their editors that way, decent or otherwise.

                        And just exactly how are tabs supposedly less portable?

                        In the same way that CR vs CR/LF issues cause portability issues; despite all text encoding including them as characters. There's no need to be obtuse. Tabs are a control character... they get 'interpreted' by the editor in a way that spaces don't. Spaces generally are treated the same as any letter or number, etc. And the portability issues arise due to the fact that there are many different ways to interpret it in common use.

                        it's a superficial description based on how you've chosen to setup your editor

                        While spaces are just spaces... I don't need to "setup my editor" to handle them. I don't want to need to 'setup my editor' to handle them.

                        • (Score: 2) by Arik on Monday June 19, @11:45AM (9 children)

                          by Arik (4543) on Monday June 19, @11:45AM (#527855)
                          "If someone told me nobody ever jumped off cliffs"

                          I never claimed people don't do stupid things, that's absurd. I'm telling you how not to be stupid.

                          "In the same way that CR vs CR/LF issues cause portability issues"

                          No, definitely not. CR vs CR/LF is not at all like this. A LF moves the insertion point down a line, while a CR moves it to the beginning of the line. On a typewriter, the return key normally triggered both simultaneously. There were subtly different interpretations of this in early implementations, so some systems expect (and produce) both a CR and a LF at the end of a line, while others expect and produce only a LF or a CR, and that means there is a very simple and straightforward conversion needed when transferring text files from one type of system to another. This issue was solved decades ago and the conversion is normally automatic.

                          There is no parallel between that and tabs. Tabs are tabs, regardless of system, there's no extra character that some systems expect and produce in proximity to a tab.

                          "I don't want to need to 'setup my editor' to handle them"

                          What I hear when I read this is "I don't want to learn to use my tools and I don't want to be competent at my job."

                          --
                          "Unix? These savages aren't even circumcised!"
                          • (Score: 2) by vux984 on Monday June 19, @02:56PM (8 children)

                            by vux984 (5045) on Monday June 19, @02:56PM (#527934)

                            I never claimed people don't do stupid things, that's absurd. I'm telling you how not to be stupid.

                            It doesn't matter what I do. Tabs vs spaces issues will continue cause problems as long as I have to work with other people. The best solution, in my opinion.

                            What I hear when I read this is "I don't want to learn to use my tools and I don't want to be competent at my job."

                            I don't know what you think my job is. My job is not to spend time configuring an editor to resolve tabs vs spaces issues in other peoples code. This is an activity that just gets in the way of doing my job. Your attempt at framing this as some sort of competency in which you take pride is comical.

                            There is no parallel between that and tabs. Tabs are tabs, regardless of system, there's no extra character that some systems expect and produce in proximity to a tab.

                            The parallel is in the special handling the editors have to do deal with the inconsistent usage across platforms. And although it is mostly solved it still crops up now and again.

                            This issue was solved decades ago and the conversion is normally automatic.

                            Quite so. This is precisely where I propose we should go with the tabs as well. Convert to spaces, let the editor figure it out, do the conversions on legacy documents automatically and invisibly so it doesn't waste our time. And if you want to vary the indent levels at the beginning of lines to suit your aesthetic preference, your editor can render leading spaces on a line wider or narrower to your preference.

                            We used to have to manually jump through hoops for CR/LF issues too. When it started happening automatically did you claim it was because people didn't want to learn their tools or be competent? Why is this any different?

                            With tabs its like you've got a hammer with a design flaw where the head keeps falling off. I've suggested we correct the flaw so we don't have to waste time putting the hammer back together all the time., and then you turned around and accused me of not wanting to be competent because being able to put your defective hammer back together is somehow your job. Ok... whatever... keep your defective hammer.

                            • (Score: 1) by Arik on Monday June 19, @07:12PM (7 children)

                              by Arik (4543) on Monday June 19, @07:12PM (#528091)
                              If your tool is a text editor and you can't be bothered to take ten seconds to figure out how to make it display text accurately and you don't see how that's not wanting to learn to use your tools then there's probably no hope for you.

                              "The parallel is in the special handling the editors have to do deal with the inconsistent usage across platforms."

                              But no, that's not accurate. No one's demonstrated any inconsistent usage across platforms. Because it doesn't exist. (There's inconsistent usage between *persons* yes but not between systems - you're trying to force this to resemble the CR/LF issue even though it does not.)

                              "Quite so. This is precisely where I propose we should go with the tabs as well. Convert to spaces,"

                              Man I'm rolling. You're either dumb as a post or you're doing a great imitation.

                              I've been trying to get someone to simply explain what the problem is and no one seems to be able to do it. I guess I'll have to explain it to you instead.

                              v>Well we have a problem. I think tabs are 3 spaces, this guy I'm working with thinks they are 8 spaces, whenever I get the file back from him it looks crazy on my screen.
                              A>Ok, so you set tabs to show as 3 spaces on your machine, and he has a bigger monitor and thinks it looks better with tabs set at 8, am I understanding you right?
                              v>That's right.
                              A>I still don't see why that's a problem?
                              v>...
                              A>ok, so sometimes he puts in a tab, which lines up fine whether on your screen or his, but sometimes he puts 8 spaces, which looks like it lines up with the tabs on his screen, but does not at all line up with the tabs on yours. Am I getting this right?
                              v>uhuh
                              A>oh and look here, you've been doing the same thing. Sometimes you hit the tab but sometimes you just hit 3 spaces. Same thing on your screen, but I guess he finds it pretty annoying on his end.
                              v>...
                              A>Ok, I see the problem, and here's the solution. Quit misusing spaces! Both of you. Spaces are for separating words, not for indenting.
                              v>I don't like that solution.
                              A>Nonetheless, it's the only logical thing to do. You're only having problems where one or both of you have introduced spaces as a substitute for tabs. There's no need to substitute them, there's no economy to be gained, tabs are not expensive or in short supply. Just use them!
                              v>No, that won't do at all. I know!
                              A...
                              v>I'll convert all the tabs to spaces. That'll solve the problem.

                              At which point A gives up and leaves v to his wallow.

                              --
                              "Unix? These savages aren't even circumcised!"
                              • (Score: 2) by vux984 on Monday June 19, @09:11PM (6 children)

                                by vux984 (5045) on Monday June 19, @09:11PM (#528151)

                                If your tool is a text editor and you can't be bothered to take ten seconds to figure out how to make it display text accurately

                                Most people don't want that feature on all the time. That's why no editor has it on by default. And few screenshots show it. The only time most people want to explicitly see the whitespace is when they are dealing with a problem with it... otherwise they prefer it off. You think I don't know how to make it display it, but that's not accurate; I know its there, i even use it sometimes but normally: I don't want it on. And I'm in the wide majority here. You are in the small minority if you want it on all the time. And its not because you are more enlightened or because we're all incompetent -- get over yourself.

                                (There's inconsistent usage between *persons* yes but not between systems - you're trying to force this to resemble the CR/LF issue even though it does not.)

                                The parallel holds up fine. The fact that the 'boundary' is by groups of users instead of on operating systems is irrelevant. There is a boundary, and the files get mangled crossing it.

                                I've been trying to get someone to simply explain what the problem is and no one seems to be able to do it. I guess I'll have to explain it to you instead.

                                You only addressed a small part of the problem. First, tabs are not a certain number of spaces. Tab is a control character which says go to the next tab stop. Tab stops are completely arbitrary. You could have them n spaces apart... or in completely arbitrary places. You could have one 30 columns in, the next at 35 columns, then the one after that at 50 columns, etc. That is a completely valid way of handling and defining tab stops. (and defining tab stops in terms of columns is ALSO not right... its properly in terms of a distance unit, so you can line up tabs when using proportional fonts. Almost no one does source code like that though because we generally like column alignment and mono-space fonts make that easier.

                                So, if your editor is defining tabs in terms of how many spaces wide it is "Tab = 8 spaces", then its already only half-assing proper tab implementation.

                                Further, its pretty common to want to write things like:

                                t     = "Fish";   //Type of animal
                                xlen  = 32;       //32 mm long
                                ylen  = 14;       //14 mm wide

                                Setting tabs as simply a width of spaces mangles this every time. THIS is why its better to just convert tabs to spaces and store spaces. There are BETTER ways to to handling different indentation preferences; such as displaying leading spaces on a line at a different width with an editor preference, and doing that will preserve the spacing/formatting in blocks of code like the sample above.

                                A>Ok, I see the problem, and here's the solution. Quit misusing spaces! Both of you. Spaces are for separating words, not for indenting.

                                You saw one problem; but missed the 2nd one.

                                Now, you could argue that the user could indent the line to the first character with tabs, and then do the rest of the intra-line alignment with spaces; but alignment of things like columns to make table-like structures is precisely the reason the tab key, and tab stops were invented; and its a pretty desirable feature. And its a pretty obnoxious restriction to prevent the user from aligning things within lines with tabs and insist he do that with spaces -- that's what TAB stops are FOR. That's why they exist.

                                So... converting tabs to spaces on the fly is a lot more sensible and predictable. You can define tab stops in your editor however you like, and use the tab key to advance to them; and let the editor handle everything else.

                                Now do you understand?

                                • (Score: 2) by Arik on Monday June 19, @09:58PM (5 children)

                                  by Arik (4543) on Monday June 19, @09:58PM (#528174)
                                  "And I'm in the wide majority here. You are in the small minority"

                                  Appeal to popularity.

                                  Stooping to such pathetic excuses for logical argument is often taken as a confession that one has no good arguments to make.

                                  "There is a boundary, and the files get mangled crossing it."

                                  No, that's still not accurate. The files get mangled earlier on. The 'boundaries' as you call it simply make the mangling more obvious to the eye.

                                  "You only addressed a small part of the problem. First, tabs are not a certain number of spaces."

                                  I'm not going to quote that entire section, but I'm flattered. It looks like you actually did read and understand part of what I wrote. Now quit trying to pretend to explain to me what I just explained to you, that's silly.

                                  "t     = "Fish";   //Type of animal
                                  xlen  = 32;       //32 mm long
                                  ylen  = 14;       //14 mm wide"

                                  You see how when I quote this, the initial double quote throws the alignment of the rest of the line off?

                                  This is exactly why you should avoid using spaces to fake tabs. Of course, in this case, the text entry field kind of forces us to do that, but it's still a great example to make the point. A tab instead of all those spaces would have preserved the alignment of the '=' signs which is what should happen, but instead, because we've faked it with spaces, we have to repair the fake tab every time the first part of the line has anything added or removed.

                                  "So... converting tabs to spaces on the fly is a lot more sensible and predictable."

                                  Yeah I'm just rolling again man. You make MY case here, right until it's time for the summation, then without any apparent reason you submit exactly the opposite conclusion.

                                  "You can define tab stops in your editor however you like, and use the tab key to advance to them; and let the editor handle everything else."

                                  Yes, but not if you have it convert them to spaces!

                                  Now do you understand?

                                  --
                                  "Unix? These savages aren't even circumcised!"
                                  • (Score: 2) by vux984 on Monday June 19, @11:45PM (4 children)

                                    by vux984 (5045) on Monday June 19, @11:45PM (#528217)

                                    Yeah I'm just rolling again man. You make MY case here, right until it's time for the summation, then without any apparent reason you submit exactly the opposite conclusion.

                                    Yeah, my thoughts exactly.

                                    Look, unless the tab stop definitions are included with the document, tabs don't work. If it was JUST for indentation purposes then it doesn't really matter, and the editor's user preference is sufficient, but as soon as the document contains any formatting beyond indents (such as the code snippet i provided) then the only thing that works is either spaces, or having the same tab stops defined. I'd be for tabs all the way if tab stops meta data was part of the the standard plaintext document format understood by everything from DOS's edit, to the unix 'more' command, to Sublime and beyond... but its not, and it never will be.

                                    "You see how when I quote this, the initial double quote throws the alignment of the rest of the line off?"

                                    Yes. And if I'd used tab stops, it might have been "thrown off" even before you put the initial quote in, if your stops were set different. How is that "better" ?? It's not better. You didn't demonstrate anything; except to illustrate the problem. I already know there is a problem.

                                    Converting all tabs to spaces on saving the document lets the document move around between systems without getting mangled just by opening it. That solves a problem we already have. And spaces is 'lowest common denominator' ... it'll work with notepad, it'll work with vi, it'll work with edit from DOS6. Source is historically a completely plaintext format, and that's a good thing. I think we can agree we shouldn't violate that tradition.

                                    The 2nd problem, of then editing that document and preserving the *behaviour* of tab stops -- I agree that this is desirable. But I think what really needs to happen is smarter editors to reinterpret the that spacing back into tabs and even infer the tab stops from the document formatting. As a human I can look at a document formatted with spaces and infer the tab stops. That's a bit beyond editors stuck in the 90s, but its not beyond us now.

                                    In other words...

                                    v:"You can define tab stops in your editor however you like, and use the tab key to advance to them; and let the editor handle everything else."
                                    A:"Yes, but not if you have it convert them to spaces!"

                                    No. EVEN if you convert to spaces. That's my proposal here. Just because they were stored as spaces doesn't mean a decent editor can't be smart about handling the alignment behavior upon loading it; and treating sequences of spaces as tabs, and inferring tab stops from format, etc.

                                    • (Score: 1) by Arik on Tuesday June 20, @01:21AM (3 children)

                                      by Arik (4543) on Tuesday June 20, @01:21AM (#528276)
                                      Well first I want to say if I sometimes come across harsh I'm not trying to be. If I really thought you were a dolt I wouldn't waste this much time on you.

                                      "Look, unless the tab stop definitions are included with the document, tabs don't work."

                                      We'll call that your thesis.

                                      "If it was JUST for indentation purposes then it doesn't really matter, and the editor's user preference is sufficient, but as soon as the document contains any formatting beyond indents (such as the code snippet i provided) then the only thing that works is either spaces, or having the same tab stops defined."

                                      And that's an interesting caveat. It IS just for indentation, yes, and using it for something else would create problems of the same sort of nature as we've been describing. You might well get away with using a tab instead of a space in a particular spot in a document on one system, but not in every spot, and when you went to another system with that file there's a good chance your initially invisible error would become apparent.

                                      But there is absolutely no need for us to have the same tab stops defined for properly tabbed files to work just fine back and forth between us. Quite the contrary, that's the entire point!

                                      To go back to an earlier hypothetical, let's say you have a fairly cramped screen and you set your tab stops at 3 spaces each, to reduce your need to scroll right. I have a big wide monitor that can manage many more readable columns than you, and I set my tab stops at 8 spaces instead. THIS WORKS PERFECTLY FOR BOTH OF US. It only becomes a problem when one of us, either one, starts inserting our preferred number of spaces and expecting that to equal a tab! It could be either one of us but I'll say it's you just for the sake of example. So it's bad enough if you only do this to the areas you rewrite. When I open the file back up I can immediately see what you've done, because it's all scrunched up with these tiny tiny little columns, and I have to go through and fix it. Once I fix it, though, it looks right not only on my screen, but it's also going to look right on your screen when I send it back to you! You get your skinny tabs, I get my fat tabs, everything lines up as it should for both of us, everyone is (or at least should be) happy!

                                      But if you go through and 'reformat' it, take out all the tabs and replace each one with three spaces each, well now you're happy but I'm very unhappy. You're seeing the same thing on your screen that you saw when it was done my way, but now I'm stuck with these ridiculously tiny indents. If I replace the tabs with 8 spaces each, you're not going to be any happier with that than I was with three. And if we compromise on 5? Great, now it looks like shit no matter which system you use to look at it.

                                      ""You see how when I quote this, the initial double quote throws the alignment of the rest of the line off?"-->Yes. And if I'd used tab stops, it might have been "thrown off" even before you put the initial quote in, if your stops were set different. "

                                      I tried very hard to figure out what you could possibly be talking about. The best I can come up with is how you can sometimes cause a minor sort of 'issue' if one person is using very wide tab stops and a lot of text between columns then the next person tries to render with much shorter tab stops. Of course in ideal world there are never any issues but this is really quite minor precisely because it's plain as day when you see that what's happened, and it's extremely easy to fix, and even better, when the person with narrow stops fixes it, that doesn't really break it for the other setup either. But I'll give you that, with some work, we can come up with a few specific situations where we're not completely happy with the results. It still seems very minor compared to the snarls that are caused going the other way.

                                      "Converting all tabs to spaces on saving the document lets the document move around between systems without getting mangled just by opening it."

                                      Yes, that is both hilarious and true. If you mangle the document when you save it, you can eliminate the need (what need again? we just established there is no need) to mangle it when you open it. Joy.

                                      Either way you've got a text where the semantically meaningful tabs have been replaced with meaning-free spaces, which means information has been lost.

                                      "And spaces is 'lowest common denominator' ... it'll work with notepad, it'll work with vi, it'll work with edit from DOS6."

                                      It only 'works' in a very low meaning as well. In fact, it would be more accurate to say that it does NOT actually work with any of them, and that seems to be why you praise it - because broken everywhere is at least *consistent* isn't that right?

                                      "No. EVEN if you convert to spaces."

                                      No, no, no. This is a one-way, lossy, conversion. It's simple to reliably convert every tab into however many spaces, but you can't just reverse the transformation because spaces are also used for other things.

                                      --
                                      "Unix? These savages aren't even circumcised!"
                                      • (Score: 2) by vux984 on Tuesday June 20, @03:21AM (2 children)

                                        by vux984 (5045) on Tuesday June 20, @03:21AM (#528315)

                                        I wouldn't waste this much time on you.

                                        It started off so pleasant... no, not 'pleastant', so ... less unpleasant. But then you said it was a 'waste of time'. Nice :)

                                        I tried very hard to figure out what you could possibly be talking about. The best I can come up with is how you can sometimes cause a minor sort of 'issue' if one person is using very wide tab stops and a lot of text between columns then the next person tries to render with much shorter tab stops.

                                        Here is a simple example if what I am talking about:

                                        Lets say you set tab stops to 8 columns and type:

                                        123456[tab][tab]line 1 -- the first tab advances to the 8th postion, the 2nd to the 16th
                                        123[tab][tab]line2 -- ditto
                                        1[tab][tab]line3 -- ditto
                                        123456789[tab]line4 -- only one tab here, but 9 chars in front, so advances to the 16th

                                        And you will get two nice neat columns; where the text "Line 1" / "Line 2" / "Line 3" / "Line 4" will all be neatly aligned on column 16.

                                        Now I have tab stops set to 3 columns and open your file:

                                        123456[tab][tab]line 1 -- the first tab advances to the 9th postion, the 2nd to the 12th
                                        123[tab][tab]line2 -- the first tab advances to the 6th position, the 2nd to the 9th
                                        1[tab][tab]line3 -- the first tab advances to the 3th position, the 2nd to the 6th
                                        1234567890123[tab]line4 -- only one tab here, but 10 chars in front, so advances to 15th

                                        Its a complete mess. Instead of 2 neat columns with the 2nd column starting at the 16th position, when I open it, every line of the 2nd column starts somewhere different. And I haven't started editing yet.

                                        No, no, no. This is a one-way, lossy, conversion. It's simple to reliably convert every tab into however many spaces, but you can't just reverse the transformation

                                        This is where we disagree. I'm not convinced it is as lossy as you think it is. I'm thinking that a bit of document analysis that I could reverse it reliably. After all, I know EXACTLY what the outcome needs to "look like" after i reverse it back to tabs; because a document saved with tabs converted to spaces has everything in the right place. Not only could i reverse the conversion, but I'd be able to tell you what the tab stops were.

                                        because spaces are also used for other things.

                                        Like what? Other than single spaces as token separators, all other spaces are just formatting and alignment. (insert usual provisos about excluding languages with semantic whitespace, and spaces between quotation marks.)

                                        • (Score: 1) by Arik on Tuesday June 20, @04:15AM (1 child)

                                          by Arik (4543) on Tuesday June 20, @04:15AM (#528332)
                                          "Its a complete mess. Instead of 2 neat columns with the 2nd column starting at the 16th position, when I open it, every line of the 2nd column starts somewhere different. And I haven't started editing yet."

                                          Yeah, that's exactly what I came up with. Only it's hardly 'a complete mess' in my eyes, it's obvious at a glance what happened and how to fix it. Tab <down> tab tab <down> tab tab tab and it's done. Nine keystrokes after setting an insertion point, does that even take a full second? The nice thing is this does NOT cause anything to break when I send it back to you. The columns will now align for both of us, and the underlying semantic content did not need to be erased to achieve that outcome.

                                          "This is where we disagree. I'm not convinced it is as lossy as you think it is. I'm thinking that a bit of document analysis that I could reverse it reliably. After all, I know EXACTLY what the outcome needs to "look like" after i reverse it back to tabs; because a document saved with tabs converted to spaces has everything in the right place. Not only could i reverse the conversion, but I'd be able to tell you what the tab stops were."

                                          I suppose that's possible, if you know a lot about the document beforehand, for instance 'it's a program in python.' Then that might be possible to do. But you'll never know if you get it right. You'll only know if it fails in a manner spectacular enough to get noticed. Why go to extra trouble just to introduce uncertainty?

                                          "Like what? Other than single spaces as token separators, all other spaces are just formatting and alignment. (insert usual provisos about excluding languages with semantic whitespace, and spaces between quotation marks.)"

                                          If one keeps introducing exceptions and exclusions it's possible to defend a false thesis by simply whittling away at it until the sliver that is left is true.

                                          And if you're dealing with a codebase that accepts code contributions from a random crowd of people, the product of varying amounts and quality of education and varying personal ability to think and absorb information, then what you're talking about might well wind up being the best technical solution to that problem. But it would still amount to deliberately breaking every file ahead of time, as a prophylactic - breaking them in a known and controlled fashion to stave off the possibility of un-known and less controlled breakage later on. Workarounds are ok - it's often hard to get things done without them - but there is real danger when the workaround sticks around and you look around and realize one day that none of the new people even realize it IS a workaround - this is the only way they've ever done it and they think it's supposed to be this way. I've seen that happen so many times.

                                          Anyway, I don't think that 'text' is completely perfect as is - tab handling is one of the areas where it could actually be improved. But please, improve it at the right level, don't slap a bunch of spaces on top of it like a bandaid and forget about it.

                                          This guy has some very interesting thoughs on the subject: http://nickgravgaard.com/elastic-tabstops/

                                          --
                                          "Unix? These savages aren't even circumcised!"
                                          • (Score: 2) by vux984 on Tuesday June 20, @04:07PM

                                            by vux984 (5045) on Tuesday June 20, @04:07PM (#528542)

                                            Yeah, that's exactly what I came up with. Only it's hardly 'a complete mess' in my eyes, it's obvious at a glance what happened and how to fix it. Tab tab tab tab tab tab and it's done. Nine keystrokes after setting an insertion point, does that even take a full second? The nice thing is this does NOT cause anything to break when I send it back to you. The columns will now align for both of us, and the underlying semantic content did not need to be erased to achieve that outcome.

                                            It was also a 3 line sample. What about a 1000 line sample. What about when there are not just two columns but 3 or 4 or 5. I spend a heck of a lot more time than "one second" fixing stuff like that.

                                            I suppose that's possible, if you know a lot about the document beforehand, for instance 'it's a program in python.' Then that might be possible to do. But you'll never know if you get it right. You'll only know if it fails in a manner spectacular enough to get noticed.

                                            That's my premise yes. that it can known what the document is, and what it is supposed to look like; so getting it right seems pretty reasonable. And if it fails (how exactly, given it knows what the output needs to be in advance); then the editor would let you roll it back; or provide additional modes/controls ... which a competent user of that editor would know how to use ;) A good enough algorithm... even if it is not perfect, it could be better than the situation we have now.

                                            This guy has some very interesting thoughts on the subject: " rel="url2html-7677">http://nickgravgaard.com/elastic-tabstops/

                                            That's pretty much what I'm talking about in terms of smart editing; where the editor infers the tabstops from the document structure etc. The theoretical advantage I see to converting to spaces on save and then reversing it is that the document alignment formatting is portable to other editors that aren't as smart.

                • (Score: 0) by Anonymous Coward on Sunday June 18, @08:37AM

                  by Anonymous Coward on Sunday June 18, @08:37AM (#527402)

                  The GP probably uses Word as its editor. There, spaces look like \cdot, while tabs look like \rightarrow.

            • (Score: 4, Touché) by MadTinfoilHatter on Sunday June 18, @03:04AM (5 children)

              by MadTinfoilHatter (4635) on Sunday June 18, @03:04AM (#527294)

              If a document has a mix of tabs and spaces, for any reason. It can look fine on one system, and get completely screwed up on another system with a different tab size

              A tab doesn't have a fixed size - that's the whole point of using them.

              Tabs always work.

              Only, as long as you *only* use tabs, which is a big assumption.

              The argument you seem to be making is that mixing tabs and spaces is bad. In what way does that translate into "therefore tabs are bad"? You could just as well say "therefore spaces are bad". Asserting that mixing the two is bad does nothing to favor one over the other.

              • (Score: 2) by vux984 on Sunday June 18, @07:26AM (2 children)

                by vux984 (5045) on Sunday June 18, @07:26AM (#527390)

                The argument you seem to be making is that mixing tabs and spaces is bad.

                Pretty much.

                In what way does that translate into "therefore tabs are bad"? You could just as well say "therefore spaces are bad". Asserting that mixing the two is bad does nothing to favor one over the other.

                No. Spaces are simple, standard, well defined, well understood, and portable. They occupy one space, like every every other normal character. And a one space separator is highly desirable. And the only way to emulate spaces with tabs is to define tabs as one space, which is what a space is; so its an absurd reduction. Conversely, you can easily emulate tab stops and tab functionality with spaces. It is ridiculous to suggest that there is nothing to favor one over the other.

                • (Score: 2) by acid andy on Sunday June 18, @09:50PM (1 child)

                  by acid andy (1683) on Sunday June 18, @09:50PM (#527608)

                  No. Spaces are simple, standard, well defined, well understood, and portable.

                  As are tabs.

                  They occupy one space, like every every other normal character.

                  Only when using a mono-spaced font.

                  And a one space separator is highly desirable.

                  Sometimes. But no-one's suggesting destroying the Space Bar.

                  And the only way to emulate spaces with tabs is to define tabs as one space, which is what a space is; so its an absurd reduction.

                  Not really. You could define a tab as a different number of spaces in your editor. It all depends on personal preference and how much text you want to fit on one line of your screen.

                  Conversely, you can easily emulate tab stops and tab functionality with spaces. It is ridiculous to suggest that there is nothing to favor one over the other.

                  Sure, you can but it becomes irritatingly inconsistent the minute you have to bring in code from another project or programmer that just happens to use a different number of spaces to you to represent an indentation. Spaces potentially allow more inconsistency than tabs when used for code indentation.

                  Also, if you indent with spaces, some simple editors might not allow you to decrease the indent as quickly by pressing Backspace as with a tab. One press of Backspace deletes a whole tab, but if there are four spaces per indent, it takes four times as many key strokes. I'll grant you this isn't an issue most of the time as Shift-Tab usually works.

                  --
                  Make hay whilst the intervening mass is insufficient to inhibit the perceived intensity of incoming solar radiation.
                  • (Score: 2) by vux984 on Monday June 19, @05:51AM

                    by vux984 (5045) on Monday June 19, @05:51AM (#527753)

                    As are tabs.

                    LMAO. Can you really say that with a straight face? Tabs are not well defined; editors treat them differently, and they are highly configurable;... that's the opposite of 'simple, well defined, and portable'. How much special programming in the editor is required to handle spaces? About the same amount as the letter 'A'... which is to say none. How custom logic to handle tabs? Tabs are pretty much the LEAST simple character used in source code.

                    Only when using a mono-spaced font.

                    That's true. Does anybody use proportional space font for source code?

                    Sometimes. But no-one's suggesting destroying the Space Bar.

                    The post i was responding too was.

                    Not really. You could define a tab as a different number of spaces in your editor.

                    The context here was someone saying not to use spaces ever, only tabs. Defining a tab as a different number of spaces, requires you to use spaces.

                    Spaces potentially allow more inconsistency than tabs when used for code indentation.

                    The code you are pasting in from another developer somwhere else, could potentially use spaces OR tabs OR both. Only the possibility of there being spaces is not going to result in 'more inconsistency' ... at worst it'll be the same.

                    Sure, you can but it becomes irritatingly inconsistent the minute you have to bring in code from another project or programmer that just happens to use a different number of spaces to you to represent an indentation. Spaces potentially allow more inconsistency than tabs when used for code indentation.

                    Decent editors can reformat code on demand. Except for python.

                    Also, if you indent with spaces, some simple editors..[...]

                    Don't use crappy editors. Some crappy editors won't cope with CR/LF issues, or unicode... either.

              • (Score: 0) by Anonymous Coward on Sunday June 18, @08:41AM

                by Anonymous Coward on Sunday June 18, @08:41AM (#527404)

                It's not that mixing tabs and spaces is bad, it's that using tabs anywhere but the first character on a line is bad. It doesn't matter if the characters preceding a tab are spaces, symbols, or letters, your carefully aligned second column will look like hell with any tab spacing setting different from your own.

              • (Score: 1, Insightful) by Anonymous Coward on Sunday June 18, @02:15PM

                by Anonymous Coward on Sunday June 18, @02:15PM (#527458)

                Tabs don't allow me to align code arbitrarily. Common use for that would be defining matrices:

                // like this
                m = Matrix2x2(1, 0,
                              0, 1)

                // instead of like this
                m = Matrix2x2(
                        1,0,
                        1,0)

          • (Score: 0) by Anonymous Coward on Sunday June 18, @03:49AM (6 children)

            by Anonymous Coward on Sunday June 18, @03:49AM (#527316)

            Sorry Buzzard, you show no grasp of logic or the bigger team/interoperability picture with your insistance that somehow tabs can be as reliable as using spaces.
            I guess this confirms why I am a programmer who takes home the highest pay.

            • (Score: 2) by The Mighty Buzzard on Sunday June 18, @03:54AM (5 children)

              Nah, my greater wisdom is just too much for PHBs and bean counters to grok.

              Tabs mean: indent this shit however far the person editing it prefers things to be indented

              Spaces mean: I like doing things incorrectly and everybody else should have to conform to my way of doing things

              --
              Save Ferris!
              • (Score: 0) by Anonymous Coward on Sunday June 18, @04:45AM

                by Anonymous Coward on Sunday June 18, @04:45AM (#527334)

                I hate mixing tabs and spaces so bad that I replace all white space with tabs. On a serious note, I don't care as long as it is consistent. Back when I did care, I just set the appropriate hooks with scripts that translated tabs to spaces and back as necessary. I guess if I had to pick, I'm a fan of the idea that items in languages should do one thing, therefore using tabs for indentation and spaces to separate tokens best fits that; and, by being consistent with usage you could help spot errors, like bad copy-pastes or misplaced new-lines.

              • (Score: 0) by Anonymous Coward on Sunday June 18, @04:19PM (1 child)

                by Anonymous Coward on Sunday June 18, @04:19PM (#527509)

                You're just ad bad you fool! "Follow the one true path! Everyone else is just WRONG and doing it their way makes you STUPID! #totallynotfascist #slittheirthroats

              • (Score: 2) by NCommander on Monday June 19, @06:02PM (1 child)

                So it was a bad thing that I just ran tab to spaces on the entirety of rehash?

                --
                Still always moving
      • (Score: 0) by Anonymous Coward on Sunday June 18, @03:32AM (7 children)

        by Anonymous Coward on Sunday June 18, @03:32AM (#527308)

        Is there actually a good reason to use spaces

        If you ever use whitespace to align things not at the start of the line, varying tab stops will break shit.

        Examples of this include right-side comments:

        void function(int arg) {
            int a=1;          //These initial guesses are selected to
            int b=99;         //minimize worst-case error at 3rd iteration.
            int c=5;          //Don't mess with them!
            ...
        }

        Or aligned arguments:

            printf("Great %s string that would make this line too %s long.\n",
                   vulgarity ? fucking[rn2(fucking_max+1)] : bleeping[rn2(bleeping_max+1)],
                   vulgarity ? fucking[rn2(fucking_max+1)] : bleeping[rn2(bleeping_max+1)]);

        Now you can argue either of those is a bad practice in itself, but even if so, using tabs makes them worse, while using spaces doesn't compound the problem. And of course, you could address these by using tabs (for initial indentation) + spaces (anywhere else), but to me any form of tabs+spaces is the worst of all options.

        • (Score: 2) by The Mighty Buzzard on Sunday June 18, @03:57AM (6 children)

          but to me any form of tabs+spaces is the worst of all options

          Exactly, so use each where they belong. Tabs indent, spaces separate. If you're using either for the purpose of the other, you are wrong.

          --
          Save Ferris!
          • (Score: 2) by deimtee on Sunday June 18, @06:09AM (2 children)

            by deimtee (3272) on Sunday June 18, @06:09AM (#527368)

            You need a law that says "No text editor or IDE will allow the combination of characters {Carriage Return}{Space} or {Carriage Return}{LineFeed}{Space}".

          • (Score: 2) by romlok on Sunday June 18, @12:38PM (1 child)

            by romlok (1241) on Sunday June 18, @12:38PM (#527436)

            I wonder if it might help people grasp the concept, if we started calling the "hard tab" character an "indent" instead.

            As in: "I press my Tab key, and it outputs a single indent character".

          • (Score: 0) by Anonymous Coward on Sunday June 18, @03:10PM

            by Anonymous Coward on Sunday June 18, @03:10PM (#527479)

            Exactly, so use each where they belong. Tabs indent, spaces separate.

            Tabs to indent and spaces to format and separate. The only way this works is if you have visible whitespace. But with this setup you can have any number of spaces for tabs and formatting will work in ALL cases.

            Then again, emacs lovers do not like any tabs :/

      • (Score: 2) by Snotnose on Sunday June 18, @05:22AM (7 children)

        by Snotnose (1623) on Sunday June 18, @05:22AM (#527349)

        People could set the way tabs are displayed: equivalent to 2, 3 or 4 spaces.

        Doesn't work that way. You end up guessing the other person's tab settings, never really knowing if you've got it right.

        Nowdays at the top of every file I work on you'll see something like "# vim: set ts=4 sw=4 noet:". If you use vim, which 90% of my co-workers do, things are set right. If you use something else you can ask me Whiskey Tango Foxtrot and I'll tell you it means tabstops are 4 and tabs are expanded to spaces.

        • (Score: 2) by Whoever on Sunday June 18, @05:39AM (2 children)

          by Whoever (4524) on Sunday June 18, @05:39AM (#527361)

          It does if you use tabs for indentation and spaces for alignment.

          • (Score: 2) by Snotnose on Sunday June 18, @06:07AM (1 child)

            by Snotnose (1623) on Sunday June 18, @06:07AM (#527367)

            So, you mix tabs and spaces, which is the worst of all worlds.

            For fuck's sake people, be consistent. Use tabs at whatever tabstop you like. Use spaces. But don't mix them the fuck up cuz those of us who have to work on your code have no fucking clue how you set things. For C/C++/Perl/ whatever, we can deal. For Python, we're fucked. In the ass. Without lube.

            • (Score: 0) by Anonymous Coward on Sunday June 18, @12:27PM

              by Anonymous Coward on Sunday June 18, @12:27PM (#527434)

              So, you mix tabs and spaces, which is the worst of all worlds.

              I think you need to clarify what you mean by "mix", because so long as every line only uses tabs for indentation, there is no mixing going on.

              For C/C++/Perl/ whatever, we can deal. For Python, we're fucked. In the ass. Without lube.

              Only if you're so inflexible as to try and force your preferred C style onto your Python code, and not attempt something more appropriate for the language.

        • (Score: 3, Informative) by Arik on Sunday June 18, @08:31AM (3 children)

          by Arik (4543) on Sunday June 18, @08:31AM (#527401)
          If you use tabs properly (to line up columns) and spaces properly (to divide words) then this 'mixture' causes no problems at all, and it is (this is important) NOT necessary to replicate any settings from the authors machine in order for things to line up properly. Your first tab stop will always represent your first level of indention, the second will represent the second, etc. and that's the underlying meaning here that has to be preserved - the order of indention. It doesn't matter if the tabs are represented by 4 spaces or 8 spaces or by a wavy purple line - what matters is that they mark successively deeper levels of indentation and nothing else.
          --
          "Unix? These savages aren't even circumcised!"
          • (Score: 2) by FatPhil on Monday June 19, @05:40AM (2 children)

            How can anyone who's never enountered a line such as

            --->--->thingy->ops.krudge_wotsit(&thingy->wotsit,
            --->--->--->--->--->--->--->--->··thingy->settings.wotsit_mode,
            --->--->--->--->--->--->--->--->··krudge_mode,
            --->--->--->--->--->--->--->--->··ostream);

            have had enough experience in the real world to command anything but the lowest level of intern's salary?
            --
            I was worried about my command. I was the scientist of the Holy Ghost.
            • (Score: 2) by Arik on Monday June 19, @11:29AM (1 child)

              by Arik (4543) on Monday June 19, @11:29AM (#527853)
              That's not a line that's quite a few of them, and so what? It's poorly formatted. Of course I've seen many poorly formatted blocks of text. What is it that you imagine that proves? Murphy's law predicts that if it's possible to do it wrong someone will do it wrong, that's a given. So what? There's no big difficulty here, as you say anyone with any real world experience should be able to fix it in seconds.
              --
              "Unix? These savages aren't even circumcised!"
              • (Score: 2) by FatPhil on Monday June 19, @02:42PM

                You show me a code metric that evaluates that line as anything apart from one line, and I'll show you a broken code metric.

                And it proves that you are unfamiliar with exceedingly common coding styles used by projects which have contributors numbering in the tens of thousands. Not being familiar with the field diminishes your ability to be taken seriously when discussing the field.

                If you think the code needs to be "fixed", then you will never get a patch in to the linux kernel, you won't even pass checkpatch.pl.
                --
                I was worried about my command. I was the scientist of the Holy Ghost.
      • (Score: 2) by andersjm on Sunday June 18, @12:10PM (7 children)

        by andersjm (3931) on Sunday June 18, @12:10PM (#527433)

        Spaces carry strictly more information. You can always convert a file with spaces to a file with tabs, but not the other way around.

        Therefore, spaces are superior as a storage format.

        If you want leading spaces to be narrower or wider than the original author intended, have your editor do it: Simply configure your editor to display leading spaces at half width or double width or whatever you like, and you can view someone else's code with whatever indentation you like.

        • (Score: 2) by The Mighty Buzzard on Sunday June 18, @01:53PM (2 children)

          You mean exactly like tabs were designed to do?

          --
          Save Ferris!
        • (Score: 2) by Whoever on Sunday June 18, @03:20PM (3 children)

          by Whoever (4524) on Sunday June 18, @03:20PM (#527482)

          You can always convert a file with spaces to a file with tabs, but not the other way around.

          That must be the most idiotic claim that I have heard in support of spaces. Of course you can convert tabs to spaces.

          • (Score: 2) by FatPhil on Monday June 19, @05:44AM (2 children)

            Not unless you *also* know the original author's tab width.
            --
            I was worried about my command. I was the scientist of the Holy Ghost.
            • (Score: 2) by Whoever on Monday June 19, @06:13AM (1 child)

              by Whoever (4524) on Monday June 19, @06:13AM (#527766)

              As long as the author followed the rule of tabs for indentation, spaces for alignment, then, no, you don't need to know the original author's tab width.

              • (Score: 2) by FatPhil on Monday June 19, @06:41AM

                Erm, how are you distinguishing indentation from alignment? You seem to be suggesting this:

                --->--->get_fooey_with_some_bars(the_great_fooinator,
                --->--->--->.....................bar_number_1,
                --->--->--->.....................bar_number_2);

                Because you'd want the extra '--->' tab for the single additional level of semantic nesting, but would want to align the arguments with '.' spaces. If you are saying that, then you're a brave man. As long as you use it everywhere consistently in your own code, and don't use it in anyone else's code, then I have no problem with that. It's internally logical, but it's vanishingly rare, which makes it practically useless. I wouldn't even know how to set my editor up to do that automatically for me.
                --
                I was worried about my command. I was the scientist of the Holy Ghost.
    • (Score: 3, Insightful) by frojack on Sunday June 18, @01:44AM (3 children)

      by frojack (1554) Subscriber Badge on Sunday June 18, @01:44AM (#527260) Journal

      I fucking hate the use of whitespace to delineate code blocks.

      It really is a mess. And another flamewar waiting to happen.

      http://wiki.c2.com/?SyntacticallySignificantWhitespaceConsideredHarmful [c2.com]
      vs
      https://unspecified.wordpress.com/2011/10/18/why-pythons-whitespace-rule-is-right/ [wordpress.com]

      There's no winning that argument. Just walk away.

      --
      No, you are mistaken. I've always had this sig.
      • (Score: 3, Insightful) by Azuma Hazuki on Sunday June 18, @02:08AM (1 child)

        by Azuma Hazuki (5086) on Sunday June 18, @02:08AM (#527273)

        Yes, there is a winning of that argument, and it is firmly on the "You want whitespace to mean something, fuck off back to TECO" side.

        • (Score: 2) by FatPhil on Monday June 19, @06:42AM

          So much blah-blah-blah nonsense in this story, almost all of which overlook the corner cases that are 90% of programming, but you basically just nailed it with one line!
          --
          I was worried about my command. I was the scientist of the Holy Ghost.
      • (Score: 2) by FatPhil on Monday June 19, @05:51AM

        from 2nd link: "Indenting a line is like adding an opening curly brace, and de-denting is like a closing curly brace."

        He starts inventing words in his opening paragraph? How can I take anything this guy says seriously, he's clearly a complete nob! Well, I could read on and see what his actual argumentation is, I won't deign to call it logic, and it's either a straw man or proof that he surrounds himself with utterly braindead people. Quite who influenced whom in that crowd I won't venture to guess. I'm guessing that if I read any further, I'm only going to see more ill-founded drivel - is it really worth my time?
        --
        I was worried about my command. I was the scientist of the Holy Ghost.
    • (Score: 0) by Anonymous Coward on Sunday June 18, @02:25AM

      by Anonymous Coward on Sunday June 18, @02:25AM (#527282)

      That's why you don't use a joke language for real work. It's about time the creators of Python were hung for their crimes.

    • (Score: 0) by Anonymous Coward on Sunday June 18, @07:12PM

      by Anonymous Coward on Sunday June 18, @07:12PM (#527558)

      I nowadays use delibarately obscure tab size with proportional font to instantly spot code that isn't written in tabsize agnostic manner.

  • (Score: 2) by Whoever on Sunday June 18, @12:57AM (8 children)

    by Whoever (4524) on Sunday June 18, @12:57AM (#527235)

    How many bytes are wasted by storing 4 spaces instead of one tab across all the source code worldwide?

    • (Score: 0) by Anonymous Coward on Sunday June 18, @01:31AM (1 child)

      by Anonymous Coward on Sunday June 18, @01:31AM (#527252)

      1. Storage is cheap
      2. Compression algorithms can strip that shit out. Wait, what...? We don't do gzipped tarballs anymore?

      • (Score: 2) by Arik on Sunday June 18, @02:04AM

        by Arik (4543) on Sunday June 18, @02:04AM (#527269)
        "1. Storage is cheap
        2. Compression algorithms can strip that shit out. Wait, what...? We don't do gzipped tarballs anymore?"

        Just because the harm can be mitigated is no reason to deliberately keep doing the thing that causes it. For this to be valid logic you'd need a third piece that you don't have, some sort of benefit to be gained by deliberately misusing spaces where tabs should be. Without such a benefit, this isn't even good sophistry.
        --
        "Unix? These savages aren't even circumcised!"
    • (Score: 3, Touché) by vux984 on Sunday June 18, @02:04AM (4 children)

      by vux984 (5045) on Sunday June 18, @02:04AM (#527270)

      "How many bytes are wasted by storing 4 spaces instead of one tab across all the source code worldwide?"

      Less than one copy of Smurfs 2 in ultra hd. So, if we can get one person on the planet who downloaded it from bit torrent to see what the fuss was about after it got cracked to delete their copy, we'll free up enough space to moot that part of this debate.

      • (Score: 2) by FatPhil on Monday June 19, @05:54AM (3 children)

        You seem unaware that the verb "to moot" means "to debate". And it's not just the verb - in English, a "moot" is a "debate".
        --
        I was worried about my command. I was the scientist of the Holy Ghost.
        • (Score: 2) by vux984 on Monday June 19, @06:03AM (2 children)

          by vux984 (5045) on Monday June 19, @06:03AM (#527760)

          You aren't wrong, but neither was I:

          http://www.dictionary.com/browse/moot [dictionary.com]

          moot :

          verb (used with object)
          5. to reduce or remove the practical significance of; make purely theoretical or academic.

          http://www.dictionary.com/browse/moot [dictionary.com]

          • (Score: 2) by FatPhil on Monday June 19, @06:31AM (1 child)

            That's why I specified "English", not "American", which is frequently an illogical bastardisation of its parent language. Don't tell me - you could care less?
            --
            I was worried about my command. I was the scientist of the Holy Ghost.
            • (Score: 2) by vux984 on Monday June 19, @02:58PM

              by vux984 (5045) on Monday June 19, @02:58PM (#527935)

              I'm not sure 'moot' as meeting is in common usage anywhere. I've read it in Tolkien that way (entmoot) but that's about it.

              Don't tell me - you could care less?

              Yes, I *could* care less. Because I do care a little.

    • (Score: 2) by Whoever on Sunday June 18, @02:08AM

      by Whoever (4524) on Sunday June 18, @02:08AM (#527274)

      A giant "Whoosh" is hereby awarded to the posters who replied without apparently realizing that I was making a joke.

      Poe's law again?

(1) 2