弹性挡片的缺点是什么？[关闭]

看这里：关于制表符和空格的典型圣战。

现在看这里：弹性的制表符。解决了所有问题，并添加了一堆非常有用的新行为。

在制表符与空格讨论中是否甚至提到了弹性制表符？为什么不？弹性制表符的想法是否存在严重的缺陷，以至于没人能在流行的编辑器中实现它们？

编辑：我很抱歉过于强调“为什么他们没有提到”。那不是我真正想要的。这个问题甚至可能是个话题。我真正的意思是，这种做法最大的弊端是什么阻止了广泛采用明显有益的想法？（在一个理想的世界中，一切已经得到支持）

（结果是，Microsoft Connect上已经有一个针对Visual Studio实现的弹性制表符的请求，在Eclipse中也有一个请求。此外，还有一个问题询问其他实现弹性制表符的编辑器）

圣战是主观的

尼克的弹性制表符是一个了不起的概念，可以帮助许多人就可行的解决方案达成共识，尽管我高度怀疑这将完全结束这场圣战：毕竟，这也是一个问题，很多程序员都不会放弃即使在妥协的代价下，他们在这个问题上的立场也只有英寸之遥。因此，这将是第一个原因。

例如，很多在“空间”方面的人仍然会不喜欢它，因为它需要在软件中添加额外的逻辑以进行良好的渲染（例如，仅在SCM的Web视图中查看变更集）。

实施问题

但是，最明显的原因仅仅是它的技术进入障碍：这与在IDE和文本编辑器中已经实施了很多年（如果不是几十年）的概念完全不同。这将需要重写它们中的一些以不同的方式处理行，这使得较旧的大型系统很难在其行处理代码中遭受深度和紧密耦合。但是，当您从头开始时，这样做要容易得多（想想Nick的演示或Go的tabwriter软件包）。

关于个人轶事，我记得前一段时间曾与作者联系，询问是否有emacs支持，在这种情况下，他提到这是其琐碎的原因。他还向社区寻求帮助，以帮助实现此功能并将其推广到大众。

我们足够在意吗？

第三个原因是，一些开发人员并没有为此事挂上电话，也不是很在乎它们会付出更多努力来支持这项工作。在大多数情况下，spaces-vs-tabs冲突不是业务障碍，因此问题背后没有太多驱动力。

如果您想要它，则必须为它而战。这在开源软件中可行。而且，如果您对其中的一部分进行了足够的更改，那么封闭源代码的用户将不得不冒着失去部分用户群的风险，即使其中很小一部分。

因此，如果您愿意，请给尼克一臂之力。

很多时候，我不得不与文字处理程序作斗争，以使文档看起来像我想要的样子，而没有一些隐藏的自动规则来控制我的文字的位置。我不想花一秒钟的时间来弄清楚为什么编辑家坚持要把那些词放在那儿。

这是我第一次听到这些。不确定它们是否是一个好主意，但是它们似乎用处不大，因为我们已经拥有一些工具（例如indent）已经可以自动格式化代码。

当我在vim中打开您聪明的弹性制表符并进行编辑时会发生什么？标签页会自动清理吗，还是一团糟？

我认为它们的主要缺点可能是破坏了diff，版本控制，并且与不支持它们的编辑器不兼容。为了支持它们，可能需要进行大量的代码修改，并且还有比“还有另一项格式化代码”功能更重要的事情。毕竟，indent如果有内存，我们都可以使用以上所有功能。

老实说，一旦您克服了最初的兴奋，我就发现它们没什么用。例如，无论如何我都不喜欢在行尾添加注释–我总是将注释放在单独的行上。这样一来，弹性片便失去了主要用途。

之后，您当然仍然可以使用它们来对齐函数参数（和参数）和一长串的分配。

但是对于前者，我倾向于将所有论据缩进一个级别，这对我来说是完全可以的：

void foo(
    int x,
    int y,
    string z
)

而且我没有看到任何需要改变这种状况。

至于分配任务，我不这样做。我在作业周围放了一个空格，就是这样。我也倾向于不将很多分配集中在一起，因此几乎没有可读性问题。

总而言之，弹性标签对我来说绝对没有用处。当然，这是一个非常个人的偏爱，可能会有所不同，但是我发现它运作良好，并且我猜想缺乏对弹性标签的支持是因为其他人也有类似的想法。

如果编辑器可以实现它们，我仍然不会使用它们。

一个缺点是，如果要在一组线上对齐然后在下一组线上缩进，则它不起作用，因为它会将相邻线的制表位停靠在一起。

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

我想要的是：

def foo( bar,
         xyzzy ):
    wibble()

对于花括号语言来说，这可能不是问题，因为您通常可以通过将花括号放在自己的一行上来解决此问题（例如在动画中），但是对于对空格敏感的语言，这很快就变得很麻烦，而您最终不得不退回到使用空格。

为什么我们不仅仅使用垂直制表符（VT，ASCII 11）来指示使用弹性制表符？它在任何主流编程语言中都没有用，但在所有AFAIK中都被解析为有效的空格。

这意味着使用弹性制表符不再是一种外部化的约定（例如，“此文件使用弹性制表符格式化，请打开它们”），而是根据具体情况选择加入的选项。

现有的文本编辑器通常显示一个字形或单个空格来代替垂直选项卡。IMO，这不是理想的，但是要付出很小的代价。

之所以没有提及它们，是因为它们没有在大多数文本编辑器的IDE中实现。它们是在项目中很少实际使用的新颖事物。

自打孔卡时代以来，就已经使用空格来布局编程。出现了制表符，显然有人认为这是个好主意（他们误解了：p）。

在当今大多数现代编辑者可以将制表符自动转换为空格的时代……它们是毫无意义的。

必须安装另一种工具来处理选项卡和空格这样的琐碎事情对我当然没有吸引力，而且我认为大多数同事都不会使用。

我认为，如果IDE支持它们（Microsoft！），它们会发现很多用处。一旦人们发现他们可以将他们的花箱拍到一边，并使其可读性好，他们就会这样做。您可能会突然将更多注释添加到源代码中（这仅仅是一件好事）。

我想我们也可以将注释“工具提示”添加到“如果...会很好吗”列表，这样您的大注释块就可以隐藏起来，并在需要时轻松查看。也许我们也可以使用注释块来构成文档的一部分（不是沙堡类型的东西，不是嵌入在代码中的正确的用户可读文档片段，而不仅仅是方法标题）

缺点：如果实际上只修改了1行（如果编辑器保存了将选项卡转换为空格的文件时），那么如果看起来像是更改了几行代码，则可能会使源diff看起来不好。或者，如果弹性选项卡是用单个字符（或更可能是2个制表符）实现的，那么在编辑器之外查看源代码可能会很糟糕。

我认为我很喜欢这个想法，但在行尾使用“制表符”可以使注释框松紧，并在随后的行（具有双制表符间距）中排列所有注释。

我是这样看的：如果大多数流行的工具已经支持弹性制表符，那么很多人就会使用它们。vi的导航/编辑模式，语法高亮显示以及后来的Intellisense也是如此。在每种情况下，既定的智慧是它没有用或不需要，但它得到了实施并开始了。

弹性挡片当然不会产生太大影响。大多数人对现状足够满意，因此不在乎。类似的推理适用于许多情况，其中有些人只是对自己所拥有的感到满意，而没有理由转向更高级的东西。换句话说，弹性制挡片的最大问题与几乎所有其他好主意相同：它需要获得牵引力。

但这并不意味着该功能不能逐步采用。即使整个团队需要一个新的编译器和一个新的IDE才能开始使用它，每种编程语言都已逐步采用。每个单独的硬件体系结构和许多其他示例都是如此。缺乏与现有工具的集成也不是阻碍因素：例如，“统一差异格式”（Unified-diff format）确实如此，该格式逐渐取代了自动化工具仍能理解的较早可读性较低的格式（例如补丁）。这些工具已随时间升级。

我很欣赏其他人提到的互操作性问题，但是尽管有这些问题，但肯定会有一些团队（如我的团队）毫不犹豫地采用整个过程。诸如diff，merger之类的外部工具最初将不支持它，但是我们会尽力鼓励供应商加入该功能。这就是始终取得进展的方式。在一个临时的过渡时期需要付出一些努力，但最终还是值得的。

我会遇到的最大问题是整个文档中的间距不一致。我知道作为一名程序员，我会很讨厌看到循环或if语句使用“标准”缩进，然后注意到不同的缩进。我个人知道我喜欢在文档中看到所有花括号，而不只是在我正在查看的代码块中。

总的来说，我认为这是一个好主意，但就我个人而言，我不希望这样做。

我刚刚尝试了jEdit的弹性制表符实现，它与我所熟悉的编程语言（主要是HTML / XML和类似C的语言）惊人地兼容。但是，使用Python代码时，其呈现方式如下（用空格代替制表符来说明事物如何对齐）：

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

对于像Python这样依赖间距的语言，除非您禁用弹性制表符提供的功能，否则这是一个大问题。如果您知道选项的名称以及如何禁用它，像Vim和Emacs这样的编辑器就可以使大多数功能的禁用变得简单，但是对于上述代码，必须禁用此功能。

话虽这么说，对于x86 ASM，C，C ++，Go，XML，HTML以及其他不太依赖空格的其他工具来说，它非常有用：

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

我会说Lisp方言（例如Scheme）有其自己的约定，这也将使弹性制表符呈现“难看的”代码。如果更改Tabstop设置以匹配2列的约定，并在不寻常的位置（在函数及其参数之间）插入Tabstop：

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

与更具可读性的：

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

诚然，这个例子并不像Python示例那样糟糕，但是肯定会降低代码的可读性。虽然我非常喜欢使用C＃或C ++之类的代码进行编码时的功能，但我却讨厌使用诸如Python或Scheme这样的语言（其中空格在功能上和/或视觉上有帮助）进行编码的功能。弹性制表符专门创建是为了帮助您而无需单独的缩进实用程序，但是显然，它并不适用于所有编程语言。

Emacs已经在有未封闭括号的情况下处理了缩进，并将自动将wilma与fred对齐。我不知道为什么Eclipse不做同样的事情。好的，我有个主意，但这不是免费的。

您也可以让Emacs对齐注释，而不会带来太多麻烦，但是AFAIK没人愿意，但是您曾经想要过。