为什么纯文本文件代表了源代码的最新状态？

确保预处理器和编译器需要查看文件的平面文件表示形式，但这很容易创建。

在我看来，某种形式的XML或者二进制数据可能表示很多很难跟踪的想法，否则。

例如，我们可以将UML图直接嵌入代码中。它们可以半自动生成，并由开发人员注释以突出显示设计的重要方面。特别是交互图。哎呀，嵌入任何用户图形都可以使事情变得更清晰。

另一个想法是将来自代码审查的注释直接嵌入到代码中。

可能会有各种辅助手段使合并多个分支变得更加容易。

我热衷的不仅是跟踪代码覆盖率，还着眼于自动化测试覆盖的代码部分。困难的部分是即使修改了源代码，也要跟踪该代码。例如，将功能从一个文件移动到另一个文件，等等。这可以通过GUID来完成，但是将它们嵌入文本文件中非常麻烦。以丰富的文件格式，它们可以是自动的并且不引人注目。

那么，为什么没有IDE(据我所知)允许我们以这种方式使用代码？

编辑：2009年10月7日。

你们中的大多数人都对我的问题中的"二进制"一词非常迷恋。我收回它。图片XML，非常少地标记代码。在将其交给普通的预处理器或者编译器之前，我们将剥离所有XML标记，并仅传递源代码。在这种形式下，我们仍然可以对文件执行所有常规操作：diff，合并，编辑，在简单而最小的编辑器中使用，将它们输入数千种工具中。是的，直接使用最小的XML标记进行比较，合并和编辑确实会使操作变得更加复杂。但我认为其价值可能是巨大的。

如果存在一个尊重所有XML的IDE，那么我们可以添加的东西远远超过了我们今天所能做的。

例如，DOxygen注释实际上看起来像最终的DOxygen输出。

当有人想要进行代码审查时，例如Code Collaborator，他们可以在适当位置标记源代码。

XML甚至可以隐藏在注释后面。

// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>

然后，如果要使用vi或者emacs，则可以跳过注释。

如果我想使用最先进的编辑器，则可以通过大约十二种不同的有用方式看到它。

所以，这是我的粗略想法。我们在屏幕上拖动的不是图片的"构建块"……我不是那么疯狂。 :)

解决方案

• 你可以比较他们
• 你可以合并他们
• 任何人都可以编辑它们
• 他们很容易处理
• 数千种工具都可以使用它们

为什么论文是用文字写的？为什么法律文件以文字形式书写？为什么幻想小说是用文字写的？因为文本是人们坚持思想的唯一最佳形式。

文本是人们如何思考，表示，理解和保留概念及其复杂性，层次结构和相互关系的方式。

我认为，将任何可能的利益与特定工具捆绑在一起是无法解决的。

使用纯文本源(这似乎是我们正在讨论的内容，而不是平面文件本身)，我可以将大块粘贴到电子邮件中，使用简单的版本控制系统(非常重要！)，将代码写到Stack Overflow的注释中，在任何数量的平台等上使用一千个文本编辑器中的一个。

使用一些二进制表示的代码，我需要使用专门的编辑器来查看或者编辑它。即使可以生成基于文本的表示形式，也不能轻易将更改回滚到规范版本中。

Smalltalk是基于图像的环境。我们不再使用磁盘上文件中的代码。我们正在运行时使用和修改实际对象。它仍然是文本，但类未存储在人类可读的文件中。而是将整个对象存储器(图像)以二进制格式存储在文件中。

但是，那些尝试过Smalltalk的人最大的抱怨是因为它不使用文件。我们拥有的大多数基于文件的工具(vim，emacs，eclipse，vs.net，unix工具)将不得不放弃，转而使用Smalltalk自己的工具。不是说在smalltalk中提供的工具逊色。只是不同而已。

具有讽刺意味的是，有一些编程构造恰好使用了我们所描述的内容。

例如，SQL Server Integration Services通过将组件拖动到可视化设计图面中来进行逻辑流程编码，并另存为XML文件，以精确描述该后端。

另一方面，SSIS很难进行源代码控制。在其中设计任何复杂的逻辑也是相当困难的：如果我们需要更多"控制"，则需要将VB.NET代码编码到组件中，这使我们回到了起点。

我想作为编码人员，我们应该考虑以下事实：对问题的每种解决方案都将带来后果。并非所有事物都可以(而且有人认为应该)用UML表示。并非所有内容都可以在视觉上表示出来。并非所有事情都可以简化到足以具有一致的二进制文件表示形式。

话虽这么说，我认为将代码转换为二进制格式的缺点(其中大多数也倾向于专有)大大超过了以纯文本格式保存它们的优点。

恕我直言，XML和二进制格式将是一团糟，不会带来任何明显的好处。

OTOH，一个相关的想法是写入数据库，也许每个记录一个功能，或者一个分层结构。围绕此概念创建的IDE可使导航源更加自然，并更容易隐藏与给定时刻正在阅读的代码无关的任何内容。

程序代码定义了将使用xml或者二进制格式创建的结构。与XML或者Binary表示相比，编程语言更直接地表示程序的结构。我们是否曾经注意到在为文档提供结构时Word的行为不当。 WordPerfect至少会使用"显示代码"，以便我们查看文档下方的内容。平面文件对程序执行相同的操作。

这是一个好问题。 FWIW，我希望看到一个Wiki风格的代码管理工具。每个功能单元将具有其自己的Wiki页面。构建工具将源代码汇集到Wiki中。将有一个链接到该页面的"讨论"页面，人们可以在其中讨论算法，API等。

哎呀，从预先存在的Wiki实现中窃取内容并不难。有任何人...吗？

我们提到我们应该使用"某种形式的XML"吗？我们认为XHTML和XAML是什么？

而且XML仍然只是一个平面文件。

整洁的主意。我自己想知道的是较小的规模……要小得多，为什么IDE X不能生成这个或者那个。

我不知道我是否有能力作为程序员来开发与我们所谈论的内容或者我正在考虑的内容一样酷而复杂的内容，但是我会对尝试感兴趣。

也许从.NET，Eclipse，Netbeans等的一些插件开始？炫耀可以做什么，并开始编码的新趋势。

Lisp程序不是平面文件。它们是数据结构的序列化。这种作为数据的代码是一个古老的想法，实际上是计算机科学中最伟大的想法之一。

原因如下：

• 可读性强。这使得在文件和解析方法中更容易发现错误。也可以大声读出。那是XML所无法提供的，并且可能会有所作为，特别是在客户支持方面。
• 避免过时的保险。只要存在正则表达式，就可以用几行代码编写一个非常好的解析器。
• 杠杆作用。从版本控制系统到编辑器再到过滤器，几乎所有内容都可以检查，合并和对平面文件进行操作。合并XML可能会一团糟。
• 能够将它们与UNIX工具(例如grep，cut或者sed)轻松集成。

人们已经尝试了很长时间来创建一个超出平面文件范围的编辑环境，每个人都在某种程度上失败了。我所看到的最接近的是Charles Simonyi的Intental Programming的原型，但是后来降级为可视DSL创建工具。

不管代码如何存储或者在内存中表示，最后，它都必须能够以文本形式显示和修改(不改变格式)，因为这是我们知道的表达大多数抽象概念所需的最简单方法通过编程解决问题。

使用平面文件，我们可以免费获得此文件，任何普通的旧文本编辑器(支持正确的字符编码)都可以使用。

我认为，另一方面是代码很重要。这将要执行。例如，在UML示例中，我认为将"源blob"中包含的UML(可能是在某些编辑器中创建的，与"代码"没有直接关系)包含在其中几乎是没有用的。最好直接从代码中生成UML，这样它就可以将代码所处的确切状态描述为理解代码的工具，而不是提醒代码应该是什么。

多年来，我们一直在针对自动化文档工具进行此操作。尽管实际的程序员在代码中生成的注释可能与代码不同步，但是JavaDoc等工具会忠实地表示对象上的方法，返回类型，参数等。它们实际上表示它们，而不是某些对象无休止的设计会议中出现的工件。

在我看来，如果我们可以将随机工件任意添加到某些"源Blob"中，则这些工件可能已过时，并且马上就没有用了。如果我们可以直接从代码中生成此类工件，那么使构建过程这样做的小努力比以前提到的摆脱纯文本源文件的陷阱要好得多。

与此相关的是，为什么要使用纯文本UML工具(UMLGraph)的解释似乎与为什么想要纯文本源文件几乎同样适用。

我想老习惯很难改掉。

直到最近，还没有许多用于结构化数据常规存储的高质量，高性能，广泛可用的库。而且，即使在今天，我也不希望将XML归入这一类别-太冗长，过于密集，无法处理，太挑剔。

如今，我最喜欢用于不需要人类可读的数据的是SQLite并创建数据库。将功能全面的SQL数据库嵌入到任何应用程序中非常容易...有C，Perl，Python，PHP等的绑定...并且它是开源的，并且确实快速，可靠且轻巧。

我<3 SQLite。

<？xml version =" 1.0" encoding =" UTF-8"？> <code>平面文件更易于阅读。</ code> </ xml>

史蒂夫·麦康奈尔(Steve McConnell)正确无误，因为我们总是为其他程序员(包括我们自己)而不是为计算机编写程序。

就是说，Microsoft Visual Studio必须在内部以非常结构化的格式管理我们编写的代码，否则我们将无法轻松进行"查找所有引用"之类的操作，也无法轻松地对变量和方法进行重命名或者重构。如果有人链接到它的工作原理，我将很感兴趣。

在阅读问题时，我们首先想到的是关于DSL的趋势。问题在于模型(如UML)与实现之间不存在一对一的关系。微软正在努力实现这一目标，以便我们可以像UML一样创建应用程序，然后可以生成代码。重要的是，当我们选择更改代码时，模型将再次反映这一点。

Windows Workflow Foundation是一个很好的例子。原因是在后台存在平面文件和/或者XML，但通常最终需要在业务流程工具中定义业务逻辑。那真是太酷了！

我们需要更多的"软件工厂"思想，并且将来会看到更丰富的IDE体验，但是只要计算机以零和一运行，纯文本文件就可以并且(可能)始终处于中间阶段。就像已经说过的几个人一样，简单的文本文件非常灵活。

实际上，大约在10年前，查尔斯·西蒙尼(Charles Simonyi)的早期有意编程原型试图从平面文件扩展到树的代码表示形式，并以不同的方式对其进行可视化。从理论上讲，领域专家，项目经理和软件工程师都可以以对他们有用的方式查看(并组合)应用程序代码，并且产品可以建立在声明性"意图"的层次结构上，从低层次进行挖掘，级别代码仅在需要时使用。

ETA(按问题的要求)Microsoft研究网站上有他早期论文的副本。不幸的是，自从西蒙尼(Simonyi)几年前离开MS创立一家独立公司以来，我认为该原型仍不可供下载。当我在Microsoft时，我看到了一些演示，但是我不确定他的早期原型的分布范围。

他的公司IntentSoft对计划向市场交付的产品(如果有的话)仍然保持沉默，但是从MSR出来的一些早期产品非常有趣。

存储模型是某种二进制格式，但是我不确定在MSR项目中披露了多少细节，而且我确信自早期实施以来，某些事情已经改变。

很明显，为什么纯文本为王。但同样明显的是，为什么结构化格式会更好。

仅举一个例子：如果重命名方法，则diff / merge / source控制工具将能够告诉我们只有一件事情发生了变化。我们今天使用的工具将显示一长串的更改，对于方法被调用或者声明的每个位置和每个文件，都有一个更改列表。

(顺便说一句，这篇文章并没有回答我们可能已经注意到的问题)

这可能无法完全回答问题，但是这里有一个编辑器，可以使我们对代码有更高的了解：
http://webpages.charter.net/edreamleo/front.html

我一直在想知道同一件事，如以下答案中所述：
我们想要什么工具/应用程序/存在什么？

容易想象有很多好处，但我认为必须解决的最大障碍是，没有人能找到可行的替代方案。

当人们想到将源存储为文本的替代方法时，他们似乎经常会立即以图形表示的方式进行思考(我在这里指的是已经可用的商业产品，例如HP-vee)。
而且，如果我们看看像FPGA设计人员这样的人的经验，就会发现(排他地)以图形方式进行编程是行不通的，因此无法使用Verilog和VHDL之类的语言。

但是我没有看到源的存储一定需要首先绑定到编写它的方法上。
来源的输入可以很大程度上以文本形式进行，这意味着仍然可以实现复制/粘贴的问题。
但我也看到，通过允许在标记化元数据源的基础上进行合并和回滚，我们可以获得更准确，功能更强大的操纵工具。

有关不使用传统文本编程的语言的示例，请参见熔岩语言。

我最近发现的另一个漂亮的东西是subtext2(视频演示)。

我认为为什么在开发中使用文本文件的原因是它们相对于各种开发工具具有通用性。我们可以使用简单的文本编辑器查看内部内容，甚至修复某些错误(我们无法在二进制文件中完成此操作，因为我们永远不知道任何修复方法会破坏其他数据)。但是，这并不意味着文本文件最适合所有这些目的。

当然，我们可以区分并合并它们。但这并不意味着diff / merge工具了解此文本文件编码的数据的独特结构。我们可以执行diff / merge，但是(特别是在XML文件中看到)diff工具将无法正确显示差异，即，它将显示文件的不同之处以及该工具"认为"数据的哪些部分是相同的。但是，它不会向我们显示XML文件结构的差异，它只会匹配外观相同的行。

无论我们使用的是二进制文件还是文本文件，差异/合并工具都最好照顾该文件所代表的数据结构，而不是行和字符。例如，对于C ++或者Java文件，报告某些标识符已更改其名称，报告某些部分被其他if(){}包围，但另一方面，忽略缩进或者EOL字符的更改。最好的方法是将文件读入内部结构并使用特定的格式规则转储。这样，将通过内部结构进行比较，并从合并的内部结构生成合并结果。

为什么文本文件有规则？因为麦克罗伊的考验。可以接受一个程序的输出作为另一个程序的源代码是至关重要的，而文本文件是最简单的方法。

有人尝试过Mathematica吗？

上面的图片来自旧版本，但这是google能给我的最好的图片。

无论如何...将第一个方程式与Math.Integrate(1 /(Math.Pow(" x"，3)-1)，" x")进行比较，就像在大多数情况下使用纯文本进行编码时一样通用语言。另外，数学表示更容易阅读，这仍然是一个很小的方程式。

是的，我们可以根据需要将代码输入和复制粘贴为纯文本。

将其视为下一代语法突出显示。我敢打赌，除了数学之外，还有很多其他东西可以从这种表示中受益。

现代程序是由扁平片段组成的，但是它们是扁平的吗？有使用，包含，对象库等。普通的函数调用可窥视另一个位置。由于具有多个线程等，因此逻辑不平坦。

Labview和Simulink是两个图形化编程环境。它们都在各自的领域中很流行(分别与PC的硬件接口和建模控制系统的接口)，但是在这些领域之外使用很少。我曾与都是这两者的忠实拥people的人一起工作，但我自己从未参与其中。

我有同样的愿景！我真的希望这会存在。

我们可能想看看Sun公司的研究语言要塞。它对源代码中的公式具有特殊的支持。以下引用来自维基百科

Fortress is being designed from the
  outset to have multiple syntactic
  stylesheets. Source code can be
  rendered as ASCII text, in Unicode, or
  as a prettied image. This will allow
  for support of mathematical symbols
  and other symbols in the rendered
  output for easier reading.

文本作为源的持久性的主要原因是缺少非文本日期的Powertools(例如版本控制)。这是基于我在Smalltalk中的工作经验，在此过程中，纯字节码一直保存在核心转储中。在非文本系统中，使用当今的工具，团队开发是一场噩梦。

Visual FoxPro使用dbf表结构存储表单，报表，类库等的代码和元数据。这些是二进制文件。它还将代码存储在实际文本文件的prg文件中。

我看到的唯一好处是能够使用内置的VFP数据语言对那些文件进行代码搜索...除此之外，它是责任制imo。至少每几个月一次，这些文件之一将毫无明显原因被损坏。与源代码控制和差异集成也非常痛苦。有一些解决方法，但是需要临时将文件转换为文本！

谁处理平面文件？

Eclipse为我们提供了源代码视图，以便我可以查看内部类，方法和数据，这些类，方法和数据都已排序和分组。如果要编辑内部类，请单击它。从技术上讲，底层有一个平面文件，我几乎从来不会像那样浏览它。

没有涉及的一件事是，某些语言具有内置的源文件的概念，例如变量作用域。更改为其他内容(例如将函数存储在数据库中)将需要我们更改语言本身。

今晚与我的朋友(程序员)一起喝酒时，他们中的一个告诉我，他们使用UML生成代码。但是他说，他们仍然需要手动编辑生成的代码，有些问题域无法使用UML轻松描述。

有了所有LINQ优缺点，lambda以及所有其他问题，有些问题域无法用UML表示，我们仍然需要围绕生成的代码进行处理，以便计算机进行出价。

我们如何用UML(更不用说XML)来表示以下问题？使用GROUP BY和COUNT(DISTINCT)的LINQ to SQL

这个简单问题的答案非常说明，UML，SQL(最重要的汇编语言，无论那些ORM家伙告诉我们什么)，XML都不是XOR命题。我们仍将使用这些技术的组合，而不是仅使用其中一种来排除其他技术。

它仍然是平面文件，因为也许这就是他们出售软件工具的方式：D

源代码本身应该是封装为成员的面向对象。我知道只有一种产品可以做到这一点，它已经存在很长时间了(Windows 3.0)，并且由Paul Allen亲自设计。它最初是受Mac上的Hypercard启发的，但正如Bill Gates所说的那样：
http://community.seattletimes.nwsource.com/archive/?date=19900522&slug=1073140

``It's generations beyond HyperCard,''
  says Gates.

不幸的是，他们没有针对合适的人：

In pursuing (interests of) software
  developers,'' says Alsop, Asymetrix
  may have made ToolBook too complex
  for the little guy.''

他们应该有针对性的专业程序员，而不是Hobbysts。

直到今天，在概念层面上，除了Rebol之外，它仍然超越了其他语言；)