On Jul 1, 2:48 am, Mark Volkmann <[email protected]> wrote: > I'm surprised that all the replies to this thread are in favor of tabs > over spaces.
I think many of us just don't feel like reopening this one; we've discussed this exact topic at least once and probably more than once on this forum, and certainly many times elsewhere. I predict that we will not reach agreement, and that this thread will go on forever, so I will just state my position once since I didn't see anyone else state the case for spaces only - and then I'll leave the thread alone. I am aware of two arguments for the mixed style (which only its supporters refer to as "The One True Indentation" Style or TOTI): 1. Tabs for indentation lets you quickly indent one level and dedent one level with the Tab character and the Delete key. Nobody seriously uses that argument anymore since all IDEs handle this automatically regardless of style -- e.g. pressing Tab is going to indent one level, and Shift+Tab is going to dedent one level. 2. "Users can set their own preferred indent size". This seems to be the main argument for the mixed style now, but: I just don't buy that use case. I guess the intention is to either (a) let you avoid horizontal scrolling if you're looking at horribly deep code, or (b) on a tiny screen, or (c) let you view code at an indentation level that is most comfortable to you yourself, if you are attached to say a 2-space indent, 3-space indent or an 8-space indent. For (a), rather than have an indent policy in your codebase to handle this, you shouldn't have any code that is so wide that it cannot be viewed properly with the standard (4 space in Java) indentation level. Break it up into subroutines. This will address (b) as well, though I don't think this is an important use case. This is 2010; people don't write code on tiny terminals anymore but solid IDEs on decent screens. For (c), I'm sorry but indentation size is only one tiny aspect of code style. Just because you can make a codefile indent in a familiar way, you're still going to have to view and accept the rest of the formatting in the file - spaces around operators and no spaces inside parentheses, no left braces on newlines, etc. Expanding tabs isn't going to make you feel at home; if you insist on reading code in your own style, you need to fully format it. Hopefully IDEs will soon let you read code formatted using your own style but behind the scenes retain the original code style and even transform your edits back to the original style. But for now, standard accepted practice is to continue whatever coding style the original source file is in (and make complete source file reformatting changes only as a separate dedicated checkin, not as part of other file edits), and playing tricks with indent size isn't going to make this meaningfully easier. As somebody else said, spaces and tabs are both invisible, so it's pretty easy for people to accidentally do the wrong thing. The minute somebody has indented one line with spaces in your scheme, it will look terrible for anyone trying to view the file with nonstandard tab settings (because for standard Java, one indent level is 4 spaces, so one tab = 4 spaces, whereas most traditional command line tools use 1 tab = 8 spaces). Yes, some of us use editor support for visualizing the differences -- Reinier uses semi-visible "show nonprintable chars"; I use a plugin to have tabs highlighted in red. But most developers don't do this, and it's pretty easy for things to accidentally break, when people use tools to make quick edits -- e.g. a file merge program, a different IDE where you haven't configured your settings yet -- and suddenly you have an inconsistently indented file. Without a more compelling reason than being able to indent code at your own depth, I just don't think mixing spaces and tabs is worth the potential trouble. -- Tor -- 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.
