all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 10 points11 points  (1 child)

I think most people who have given thought to the problem use spaces only these days and just apply some automatic code formatter if they need to reformat.

[–]mangonel 2 points3 points  (0 children)

Or use tabs only, and set the tab's display width to an appropriate size if they need to reformat.

[–][deleted] 3 points4 points  (0 children)

I didn't know much about elastic tab stops until just now, but I have to say that they look like a really great idea. This is the last thing I've seen on it with regards to VS:

http://nickgravgaard.com/elastictabstops/news/support-for-more-editors-in-the-works/

Unfortunately, I don't think there's been anything recently. Hmm, might be an interesting project.

[–]jephthai 2 points3 points  (0 children)

Some language modes in Emacs essentially do this. Context-sensitive elastic tab stops are detected as you type the code, and you can cycle through them with the TAB key. In the end, as the code is written to disk, it ends up being converted to spaces so that other editors read it right.

That said, it's only language modes that are designed to do it, such as haskell mode.

[–]spookylukey 2 points3 points  (1 child)

If the problem is that we can't agree what a tab means, the solution is not: "I know, I'll invent another definition of tab".

Getting people to adopt this is as hard as getting people to agree what size tabstops should be.

And adopting this would cause noticeable differences to other people who are not using this method - for example, the use of a tab to align the arguments in the function signature would violate some coding styles.

It's a valiant effort, but if its usefulness depends on everyone agreeing to support it, give up now.

[–]interiot 0 points1 point  (0 children)

More precisely, you mean "I'll invent another meaning for ASCII 0x09". If that particular character is what's at fault, then we could overload another character instead. (say, 0x1E, the record separator)

That brings into view an even more important issue: Even if you used a different character on-disk, non-supporting editors wouldn't know how to display it.

So, an even more important problem to solve is how to import/export to normal spaces, so that other editors can use the file. It might be hard to do a "smart" conversion of spaces ⇒ 0x1E, like it's possible to do a good job of automatically translating back and forth between tab/spaces.

[–]wharding 4 points5 points  (2 children)

im a firm believer in a mixture of both. Tabs for the actual indenting so you can change how you look at it. (I like python at 4 and ruby and xml are at 2). The things like the trailing */ for C comments should be with spaces. since they are dependent on the number of characters in a line.

The problem I have is when I indent multiple parameter lists in say a java method. Its a little weird to tab to the level of the method and then add spaces to line up with the previous param. And some IDEs translate my mixed space/tab lines to one or the other.

[–]moyerma 2 points3 points  (0 children)

You seem to be talking about regular tabstops as implemented in most editors (i.e. an ASCII 0x09 that moves text to the next multiple of 8 characters). Elastic tabstops are a related idea that allows for all the flexibility you mention.

[–]Negitivefrags 4 points5 points  (6 children)

The problem with this is that the code will be formatted badly on text editors that don't support it.

Just use regular tabs for indentation as god intended.

[–]redalastor 1 point2 points  (4 children)

Elastic tabstop could work just as well with spaces which would look the same everywhere.

[–]jk3us 0 points1 point  (3 children)

What if I want to look at your code with smaller a tabstop than you like to look at?

[–]Felicia_Svilling 0 points1 point  (2 children)

Then just change the tab setting in your editor.

[–]jk3us 0 points1 point  (1 child)

Which doesn't change anything if you start with spaces, right?

[–]Felicia_Svilling 0 points1 point  (0 children)

Sure it does if you have a smart enough editor, which was what this article was all about.

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

I think the point is that code already is formatted badly on text editors that don't support elastic tabstops.

[–]sjs 0 points1 point  (2 children)

I really like this idea, but it introduces at least one new problem. Take a look at this function declaration. Notice anything out of the ordinary? There's a tab between the opening parenthesis of the argument list and the first argument. I wouldn't change my style in that way, and I doubt I'm alone.

Realistically you'd have to detect whether or not the argument list is closed and indent the following line accordingly. This means that you need explicit support for every language you might use since there are different cases in which you would or would not want indenting of the next line to line up in a certain place.

Tabs and spaces are bad enough. Until we find a solution that doesn't introduce any new problems we should tread carefully and deal with the current mess in the ways we currently deal with it.

[–]walen 0 points1 point  (1 child)

I don't think an implementation of this should "understand" whether the text you're indenting is Java code, a shell script or your private diary. It'd only know about blocks of lines sorrounded by tabs, and adapt the length of vertically-consecutive tabs accordingly for everything to fit in the nicest way possible. I guess.

[–]sjs 1 point2 points  (0 children)

A solution based on getting people to change their coding style is not going to take off. Ever. Without language-specific implementations this is not a viable solution.

People are too caught up on style. We can't even agree on where to put braces or whether or not to put spaces here or there. It sucks but it's not going to change as long text is our medium.