This belongs to a common class of arguments that I call the: "My fellow programmers are idiots" argument.
It doesn't ring true for me. It's programming, turing complete and all. The idiot-proof programming language has not been invented yet. The argument needs to be more nuanced than that; if we are to assume our fellow programmer doesn't know what he's doing, we're already doomed no matter what you do. Is screwing up TOTI by accident more likely than screwing up all spaces by accident? The flipside argument to "My fellow programmers are idiots", which doesn't work as an argument, is "We're all idiots some of the time", which works quite well; I doubt any one of us has never run into a situation where they review their own code and go: That was ME??!? Cripes. I should fire myself. In addition, this yet again feels like a meta-argument to me: What makes the all-spaces rule so much easier to enforce than TOTI? I wholly agree that folks tend to screw up the formatting, but that's why you can (A) turn on 'show whitespace' in your IDE, (B) have an auto-formatter handy, and (C) add some warning flagger routines to your git setup so seemingly screwed up spacing is flagged down. Lots of code is effectively single programmer; only one person is working on it, and sweeping changes are usually done by refactor script, which presumably sticks to the formatting as the IDE will be generating it. For code which is either multi-programmer, or when you're looking at other folks' code, just hit auto-format before you look at it. I think it's a bit drastic to claim that a few bad apples produce an utterly bad result. Maybe, but that bad result is trivially fixed. On Jul 1, 3:13 pm, Jess Holle <[email protected]> wrote: > The real issue is that many developers can't handle always using tabs > for indenting and always using spaces for spacing -- it's too much for > them, in part because the difference is invisible and thus mistakes only > become obvious to those with different tab stop settings. > > All it takes is a few bad apples to produce an utterly bad result. Thus > in the real world with multiple real world programmers working on the > code any use of tabs becomes intolerable. > > -- > Jess Holle > > On 7/1/2010 8:03 AM, Reinier Zwitserloot wrote: > > > > > In regards to the 'you can't mix and match' rule 3: Actually, The One > > True Indent style *DOES* mix and match. Specifically, it mixes 'tabs > > are for indents' and 'spaces are for spacing'. > > > Furthermore, the general complaint "Do not randomly mix indent styles" > > is of course applicable, but this is a meta-rule. I don't really see > > how you can claim that this is a problem with The One True Indent > > style any more than it is with the all-spaces indent style. It is true > > that some editors offer an easy "all spaces please" option, and TOTI > > is less common, but that's a problem with your tools. The major 3 IDEs > > can all be configured to auto-format in TOTI style. > > > In regards to rule 4: That's misleading as well. TOTI at least offers > > a future where viewing source on a tiny mobile phone screen is going > > to go ever so slightly better because of configurable tab stops. With > > spaces you have to pick the same indent length for all devices; > > presumably 4, but on a mobile phone you'd definitely want no more than > > 2. Again this argument seems either a wash or if anything in favour of > > TOTI over all-spaces. > > > On Jul 1, 12:27 pm, Paul King<[email protected]> wrote: > > >> I tend to be in the 'tabs are evil camp' most of the time. Not that they > >> are > >> evil but there are some missing rules in Reinier's list. Rule 3: If you use > >> tabs you must use them everywhere - you can't mix and match and everyone > >> else must too. Rule 4: Every tool in your toolset including all future ones > >> must support and allow customisation of tab sizes. If I am browsing source > >> diffs through fisheye and it converts tabs to 8 spaces for display > >> purposes, > >> that might be fine on a large screen but less useful on a mobile phone. In > >> fact, this is the exact scenario where tabs could be so useful but with > >> many > >> tools, they just aren't right now. It's certainly better than it was 10 > >> years ago but still has some way to go IMHO. > > >> Still, it's not something to get too worried about - you should be able to > >> convert from one style to the other with a keystroke in most IDEs. > > >> Paul. > > >> On Thu, Jul 1, 2010 at 7:48 PM, Mark > >> Volkmann<[email protected]>wrote: > > >>> I'm surprised that all the replies to this thread are in favor of tabs > >>> over spaces. In my experience, the vast majority of developers favor > >>> spaces. For me there is one main reason I prefer spaces ... printers. > >>> Sometimes I print code. Printers seem to always use eight spaces for > >>> tabs which causes many lines to wrap and makes it harder to read the > >>> code. If there were a universal way to adjust that then I'd be okay > >>> with using tabs for indentation. > > >>> This is the same reason why I don't like when lines are longer than 80 > >>> characters. Many of the lines will wrap when printed. Also, I find it > >>> harder to read code with long lines. That's why newspaper columns > >>> don't extend all the way across wide newspaper pages. > > >>> -- > >>> R. Mark Volkmann > >>> Object Computing, Inc. > > >>> -- > >>> 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]<javaposse%2bunsubscr...@googlegroups > >>> .com> > >>> . > >>> For more options, visit this group at > >>>http://groups.google.com/group/javaposse?hl=en. -- 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.
