我正在阅读《代码完成》，在有关布局和样式的章节中，他预测代码编辑器将使用某种格式的富文本格式。这意味着，而不是像这样的代码

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

它可能看起来像这样：

程序 ResolveCollisions

通过空间划分算法执行后验碰撞解决

参量

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

局部变量

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

我看过语法着色和突出显示，甚至括号着色，但是在实际代码中没有什么看起来像这样。我想知道这种事情是否真的存在，或者是否确定它没有足够的利益，或者这完全是一个坏主意。

你们中有没有人曾经看过像这样的格式丰富的代码，或者知道这个主意是否曾被考虑并最终被拒绝？

没有技术原因，您不能这样做。如果文本编辑器可以突出显示语法，则他们可以轻松地将显示的其他方面更改为突出显示代码。

但是，随着编辑器弄清楚您要键入的内容，键入的内容更改颜色是一回事。让文本突然改变大小并在键入时跳来跳去会真的很令人讨厌。

但是，对于“静态”代码显示，您可以轻松美化源代码。例如，使用任何中间合适的source-> html转换器，然后将所需的任何字体大小和样式添加到样式表中，您将获得格式丰富的代码。

简单原因：编辑器/工具独立。

一旦您使代码变得“丰富”（它将与您所使用的编辑器联系在一起），或者与可以理解丰富代码的人联系在一起。所有其他无法处理丰富性的编辑器都会显示乱码。

同样，丰富的代码无法与diff工具一起使用。例如，如果您只是更改了某些格式，则差异将显示差异，但您最不用担心的差异也不会。

那版本控制呢？您如何告诉它忽略格式中的所有更改，仅当存在一些“实际”更改时才将文件视为已修改。

最后，我想，丰富代码的全部要点是可读性，为此，我认为更好（和更多）的注释，逻辑标识符名称和一致的缩进就足够了。

本质上，最好将编程文本作为纯文本处理-您所看到的是实际情况。（这也符合Pythonic的显式优于隐式的思想）

也许格式丰富的代码尚未流行，因为它不是一个好主意。就个人而言，我不喜欢在您提供的示例中看到的内容。我使用语法着色和突出显示，但是这种格式设置过于繁琐，与我习惯于查看和编写代码的方式有很大不同。

为什么不存在？没有需求/需求。

当前的编辑器能够通过语法突出显示和其他一些次要的样式选择来满足程序员的需求。那不是“富文本”吗？

对于Emacs，在AucTeX模式下的LaTeX已经存在。章节标题的尺寸较大，子标题和上标的大小也将适当调整，您甚至无法预览数学（以及其他可能使用算法的环境）。

这是乳胶很好，因为从代码到输出的映射通常为多比其他方案更简单; 对于更通用的语言，我想一点都不喜欢。

另一件事Emacs可以做的是更换相同的符号，->并forall用→和∀分别在Haskell。几乎没有理由将这种事情不能扩展为进行格式化（如您所建议的那样），只是在Haskell中根本没有必要。

前段时间，我问了有关代码格式化的问题，询问程序员是否要在键入时对代码进行格式化。

我的问题仅涉及格式的缩进方面，但一般而言，某些答案可能完全适用于代码格式。答案中的总体观点表明，程序员反对失去对其代码表示方式的绝对控制。

我的个人经历截然不同。尽管我通常使用公开可用的工具，但有时我需要在自己的定制编辑器中编写XSLT。当我键入该代码时，该编辑器通过向左缩进缩进来格式化代码，这样我就不会出现不需要的空格（在XSLT中很重要）的问题，并允许我的代码自动换行并仍然保持格式。我发现这种体验很自然，格式样式仅由换行的上下文和位置控制（使用触摸感应输入设备时，这种体验特别有益）。

如果XSLT的平衡不佳，那么格式实际上有助于显示问题所在。在键入时花了一段时间来适应水平移动的代码，但对我而言，这不再是分心的事情。但是我确实发现影响XSLT垂直间距的格式化功能使编辑器几乎无法使用，因此我禁用了这些功能。

回到您的问题，我认为丰富的代码格式之所以不普遍的原因是，在编程世界中改变观念需要很长时间。时间到了，可能与主要不使用键盘进行代码编辑的时间相吻合。

缩进在多种语言（Haskell，Ruby，Python，Erlang，CoffeeScript等）中也很重要。因此，如果要更改字体大小，可能很难弄清楚。

主要是它的传统。我从事专业编程已有近20年的时间，我怀疑这会让我发疯。我使用docbook在Emacs或VI中写书，所以我不是所见即所得的粉丝

Knuth的CWEB可以做到这一点，但仅适用于C / C ++和Pascal。—不过，您应该看一下……它非常整洁。有两个程序：ctangle和cweave，它们分别将CWEB文件组合/分离为TeX和C。

你们中有没有人曾经看过像这样的格式丰富的代码，或者知道这个主意是否曾被考虑并最终被拒绝？

当然。Xcode支持简单语法以外的样式，以用于不同的语法：

自从我使用它已有很长时间了，但是我认为Metrowerks CodeWarrior也支持样式化文本，而那是10年前的事了。

但是，您不希望过分关注样式-当样式变化太大时，任何文本，源代码或其他内容都可能更难以阅读。特别是，我认为混合大小会分散注意力，任何导致列不对齐的事情都是令人讨厌的。大多数程序员仍然使用等宽字体是有原因的。

另一个问题是样式文字是否应作为语言语法本身的一部分使用。例如，编译器是否应使用某些文本已设置样式的事实来确定该文本是函数声明？乍一看听起来很疯狂，但是Python和Fortran等语言已经使用缩进作为语法。尽管如此，我认为我们更有可能继续看到语法是由语法驱动的，而不是相反。能够使用纯文本有很多好处（更简单的编译器，平台独立性，程序员偏好），并且其他一些传统已发展为使代码在没有样式（缩进，空行，标记字符和编辑器功能，例如代码折叠和导航菜单）。

我认为，丰富的源代码格式不是很流行，因为它用于信息输入，而结构和含义要重要得多（也更容易键入）。字体化，额外的特殊符号和空格只会增加不必要的视觉噪音。不过，它可能适用于生成的文档。

在排版世界中，喜欢使用所见即所得的编辑器（例如MS Word）和喜欢TeX（LaTeX）的系统之间永无休止的战争。

通常，没有确定的答案。这完全取决于工具，用例和个人喜好。

诸如Doxygen或JavaDoc之类的工具已经执行了富文本代码格式。它们还添加了代码超文本以供浏览。您不需要为基本格式插入特殊标签。

这不是所见即所得。

恐怕这确实存在。

过去，我曾研究过某些Centura（也称为Gupta或SQL / Windows-旧的“ 4GL ”）代码。实际上不可能在标准的编辑器（如记事本）中将Centura代码编辑到所需的极端格式。

虽然看起来像这样格式化源文件似乎是一个好主意，但我发现开发过程非常繁琐。

此外，在源代码管理中合并时，格式化经常会引起问题。

除了其他答案，我想指出，除了使用丰富格式的技术难题之外，这也是个人喜好的对象。

如果您编辑纯文本，则可以选择所需的字体和颜色，它们是自动设置的。如果您要编辑RTF，如果您不喜欢手动设置的特定颜色和字体怎么办？

我认为这是因为还没有人将代码读取和代码写入分开。至少它还没有成为主流。有时，您必须阅读您很久以前接触过的代码或其他开发人员创建的代码。您可能需要花费很多时间才能准备好更改此源中的单个字节。这可能是“读取”模式，可以执行所需的任何操作以使其更容易理解（字体大小，重新格式化，下标脚本，上标脚本等）。当您准备就绪时，编辑器可以切换到“写入”模式，并减少限制，而更多地遵循“最少惊喜的规则”