Carl, if some tool makes some code look screwed up, that code couldn't possibly have been indented with the TOTI style; it is tabstop independent. At best the argument here against TOTI is that 8 chars per tabstop is rather extreme, and some tools do not default to 4 and do not allow you to configure it to something else. However, the very arguments used against the benefits of tab stop independence (we got big screens now!) kills that particular argument as well.
Code containing tabs that isn't TOTI-style is as annoying to me as it is to you. However, throwing the baby out with the bathwater and declaring a holy war against tabs is a bit of an overreaction, no? The problem is primarily mixing spaces and tabs to indent (the old sun style, where an indent is 4 characters, tabs are eight, and indents are collapsed, which is clearly the stupidest indent system I've ever heard of, period), and very rarely that folks have been using tabs for spacing (simply because spacing out code is relatively rare). That's the stuff that ought to be banned. On Jul 1, 6:39 pm, carl <[email protected]> wrote: > Here here. I'm with Tor. > > The proponents of the Tab Indentation Style (TIS) claim that the > flexibility of the tab allows the readers to adjust the indentation to > their preference. But as Tor points out, this is just one small piece > of the overall code style and allowing just this one degree of freedom > is so limited to be pointless. The other problem that has ben pointed > out, is that there are so many tools that we use to look at source in > different contexts, that it is impossible to configure them all to > always do what we want. Whenever I see source with screwed up formats > in viewers (diff, fisheye, etc) it's always due to tabs being wrong. > Yes, sometimes it is due to bad mixing of spaces and tabs, but > sometimes it is just that different authors used tabs with different > width settings. The code always looks perfect in all tools when it is > indented with spaces. > > I'd like to add another dimension that the indentation and left > alignment of source elements do interact in most formatting styles. > Even if you don't go for the "ASCII-art" column alignment style (and I > don't), it is still very desirable, to align indented things with text > positions, like long wrapped parameter lists with the left edge of the > first parameter. You can't do this with tabs. You can only do this > with spaces (and a fixed width font). > > So, that leads to the discussion of source being stuck in a world of > plain text and fixed width fonts. I do see how it would be nice to > edit code with the richness of text like Fortress. But there is also > beauty in Plain Old Text. How many of our data formats have evolved > over the last few years from custom binary formats to plain old text? > XML? JSON? CSV? There's something to be said for universality. > > We have our IDEs to do the really smart, language-sensitive formatting > and wrapping and indenting as we edit. But after that, most tools are > not capable of that degree of rendering. While it would be nice to > keep source simple and pure and unformatted, letting the viewer render > it how we like at the moment, we live in a world where we must rely on > the IDE to "prerender" the source into a fixed pretty format for the > down stream tools to consume. > > --carl -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
