It's basic ecology...

Tabs take up fewer characters than multiple spaces
fewer chars = smaller files = faster checkins, etc.

I wonder what the carbon footprint is of manufacturing all the HDD used
globally to store superfluous spaces?



On 1 July 2010 16:20, Tor Norbye <[email protected]> wrote:

> 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]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>


-- 
Kevin Wright

mail/google talk: [email protected]
wave: [email protected]
skype: kev.lee.wright
twitter: @thecoda

-- 
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.

Reply via email to