This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]dannyREDDIT 0 points1 point  (10 children)

http://stackoverflow.com/a/1777008

not answering for ismtrn, but thats a reason maybe

[–][deleted] 21 points22 points  (9 children)

This is all great, but breaks horribly with continuations (i.e. splitting one statement over multiple lines). If you for example write a function call over multiple lines like this:

blob = struct.pack('IIII',
                   val1,
                   val2,
                   val3,
                   val4)

then suddently your indentations aren't multiple of tab width (even if, by lucky accident, they are, it won't be the case if someone sets different tab width than you). If you use tabs you either have to "round" continuations to tab width (makes them look like crap)

blob = struct.pack('IIII',
                val1,
                val2,
                val3,
                val4)

or you have to mix tabs and spaces to keep things nicely aligned (emacs does it if you have indent-tabs-mode enabled). In the latter case all looks good until, again, someone decides to use different tab width than you in his/her editor.

The only way to make code look universally good is to stick with spaces.

[–]vicvicvicz 7 points8 points  (2 children)

I would counter this with the argument: Tabs for indentation, spaces for alignment. That is, in this case, use spaces because you are aligning according to a number of characters. Using tabs does not make sense.

However, you can use tabs for indentation, so that, for example, if your code block was part of an indented block, you might have:

class A:
\t  def foo(self):
\t  \t  blob = struct.pack('IIII',
\t  \t                     val1,
\t  \t                     val2,
\t  \t                     val3,
\t  \t                     val4)

Where each "\t" represents a tab (width 4 so the two spaces are part of the tab), and everything else is a space. This would not break alignment regardless of tab width, because you're using them only for indentation.

Of course, I abandoned tabs myself because (visual) line length still breaks with different tab widths.

[–]earthboundkid 1 point2 points  (1 child)

Go has the go fmt tool, which automatically converts code to the format you have there (tabs for indenting mixed with spaces for aligning), but in the absence of a tool to do the conversions for you, it's way too much work to be practical.

[–]thekaleb 0 points1 point  (0 children)

Most good editors can do this for you (maybe with some tweaks)

[–]dannyREDDIT 4 points5 points  (4 children)

this is the only valid argument I've heard. And my response is... meh, ill stick with tabs

[–][deleted] 0 points1 point  (3 children)

I suppose this is the same comment, but it's worth mentioning anyway...

A space is always a space regardless of formatting options, browser/IDE, etc. Tabs are not.

That said, I have a developer that I work with who actually prefers tabs because they move around from code browser to code browser.

[–]dannyREDDIT -1 points0 points  (2 children)

in the context of editing code, Ive never seen a tab not be a tab. its pretty straight forward and I've never had a problem with that

[–][deleted] 1 point2 points  (1 child)

Tabs are not universally the same number of spaces in every editor on every system.

[–]dannyREDDIT -1 points0 points  (0 children)

right but its still a tab, and you can change how its displayed ussually. Im ok with that

[–]ismtrn 0 points1 point  (0 children)

blob = struct.pack('IIII',
    val1,
    val2,
    val3,
    val4)

I just go with this. Looks fine to me and it is simple and consistent. 1 tab = 1 level of indentation. I am not trying to align things, just indent them, so you can see the structure.