flat-file - 为什么我们仍然使用平面文件进行编程？

Question

为什么平面文本文件是表示源代码的最先进技术？

当然——预处理器和编译器需要查看文件的平面文件表示，但这很容易创建。

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

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

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

可能有各种帮助可以更轻松地合并多个分支。

我感兴趣的不仅仅是跟踪代码覆盖率，还包括查看自动化测试覆盖的代码部分。困难的部分是跟踪该代码，即使源被修改。例如，将一个函数从一个文件移动到另一个文件，等等。这可以通过 GUID 来完成，但是将它们直接嵌入到文本文件中会比较麻烦。在丰富的文件格式中，它们可以是自动且不引人注目的。

那么为什么没有 IDE（据我所知，无论如何）允许您以这种方式处理代码？

编辑： 2009 年 10 月 7 日。

你们中的大多数人都非常关注我的问题中的“二进制”这个词。我收回它。图片 XML，非常少地标记您的代码。在你将它交给你的普通预处理器或编译器之前的那一刻，你去掉了所有的 XML 标记，只传递了源代码。在这种形式下，您仍然可以对文件执行所有常规操作：差异、合并、编辑、在简单且最小的编辑器中使用，将它们提供给数千个工具。是的，直接使用最少的 XML 标记进行差异、合并和编辑确实有点复杂。但我认为价值可能是巨大的。

如果存在尊重所有 XML 的 IDE，那么您可以添加比我们今天所能做的更多的东西。

例如，您的 DOxygen 评论实际上可能看起来像最终的 DOxygen 输出。

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

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

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

然后如果你想使用 vi 或 emacs，你可以跳过评论。

如果我想使用最先进的编辑器，我可以通过十几种不同的有用方式看到这一点。

所以，这是我的粗略想法。这不是你在屏幕上拖动图片的“积木”......我没那么疯狂。:)

score 140 · Accepted Answer

你可以区分它们
你可以合并它们
任何人都可以编辑它们
它们简单易处理
成千上万的工具可以普遍使用它们

score 25 · Accepted Answer

在我看来，任何可能的好处都超过了与特定工具相关联的好处。

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

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

score 14 · Accepted Answer

Smalltalk 是一个基于图像的环境。您不再使用磁盘文件中的代码。您正在运行时处理和修改真实对象。它仍然是文本，但类不存储在人类可读的文件中。相反，整个对象内存（图像）以二进制格式存储在文件中。

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

score 11 · Accepted Answer

为什么论文是用文字写的？为什么法律文件是用文字写成的？为什么奇幻小说是用文字写成的？因为对于人们来说，文字是坚持思想的唯一最佳形式。

文本是人们思考、表示、理解和坚持概念的方式——以及它们的复杂性、层次结构和相互关系。

score 11 · Accepted Answer

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

score 8 · Accepted Answer

8

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

于 2008-10-02T04:52:57.277 回答

score 7 · Accepted Answer

这是个好问题。FWIW，我很想看到一个 Wiki 风格的代码管理工具。每个功能单元都有自己的 wiki 页面。构建工具将源代码从 wiki 中提取出来。会有一个链接到该页面的“讨论”页面，人们可以在其中讨论算法、API 等。

哎呀，从预先存在的 Wiki 实现中破解一个并不难。有没有接盘侠...？

score 7 · Accepted Answer

原因如下：

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

score 5 · Accepted Answer

具有讽刺意味的是，有些编程结构精确地使用了您所描述的内容。

例如，SQL Server 集成服务涉及通过将组件拖入可视化设计表面来编码逻辑流程，它被保存为精确描述该后端的 XML 文件。

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

我想，作为编码人员，您应该考虑这样一个事实，即对于问题的每个解决方案都会产生后果。并不是所有的东西都可以（有些人认为应该）用 UML 来表示。并不是所有的东西都可以直观地表现出来。并非所有内容都可以简化到足以具有一致的二进制文件表示。

话虽如此，我认为将代码降级为二进制格式（其中大部分也往往是专有的）的缺点远远超过了将它们放在纯文本中的优点。

score 5 · Accepted Answer

人们长期以来一直在尝试创建一个超越平面文件的编辑环境，但每个人都在某种程度上失败了。我见过的最接近的是 Charles Simonyi 的 Intentional Programming 的原型，但后来被降级为可视化 DSL 创建工具。

无论代码如何在内存中存储或表示，最终它都必须能够以文本的形式呈现和修改（您无需更改格式），因为这是我们所知道的表达大多数抽象概念所需的最简单方法通过编程解决问题。

使用平面文件，您可以免费获得它，并且任何普通的旧文本编辑器（具有正确的字符编码支持）都可以使用。

score 4 · Accepted Answer

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

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

score 4 · Accepted Answer

史蒂夫·麦康奈尔（Steve McConnell）一如既往地正确——您为其他程序员（包括您自己）编写程序，而不是为计算机编写程序。

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

score 4 · Accepted Answer

实际上，大约 10 年前，Charles Simonyi 的意图编程早期原型试图超越平面文件，进入可以以不同方式可视化的代码树表示。从理论上讲，领域专家、PM 和软件工程师都可以以对他们有用的方式查看（并拼凑）应用程序代码，并且产品可以构建在声明性“意图”的层次结构上，深入挖掘仅根据需要进行级别代码。

ETA（根据问题中的要求）在 Microsoft 研究网站上有一份他的早期论文的副本。不幸的是，由于 Simonyi 几年前离开 MS 成立了一家独立的公司，我认为原型仍然无法下载。我在微软的时候看过一些演示，但我不确定他的早期原型的分布范围有多广。

他的公司IntentSoft仍然对他们计划向市场提供的产品（如果有的话）保持沉默，但 MSR 的一些早期产品非常有趣。

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

score 3 · Accepted Answer

我猜旧习惯很难改掉。

直到最近，用于结构化数据的一般存储的高质量、高性能、广泛可用的库并不多。即使在今天，我也坚决不会将 XML 归入该类别——太冗长、太密集而无法处理、太挑剔。

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

我 <3 SQLite。

score 3 · Accepted Answer

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

score 3 · Accepted Answer

Labview和Simulink是两个图形化编程环境。它们在各自的领域都很受欢迎（分别从 PC 和建模控制系统连接到硬件），但在这些领域之外没有太多使用。我和那些都是他们的忠实粉丝的人一起工作过，但我自己从来没有接触过他们。

score 2 · Accepted Answer

有人试过Mathematica吗？

上面的图片来自旧版本，但它是谷歌能给我的最好的。

无论如何...将那里的第一个等式与Math.Integrate(1/(Math.Pow("x",3)-1), "x")进行比较，就像您在大多数情况下使用纯文本编码时必须编写的那样共同语言。Imo 数学表示更容易阅读，这仍然是一个非常小的方程式。

是的，如果需要，您可以将代码作为纯文本输入和复制粘贴。

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

score 1 · Accepted Answer

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

此外，XML 仍然只是一个平面文件。

score 1 · Accepted Answer

我们看到的关于 DSL 的趋势是阅读您的问题时首先想到的。问题是模型（如 UML）和实现之间不存在一对一的关系。微软和其他公司正在努力实现这一目标，以便您可以将您的应用程序创建为类似 UML 的东西，然后可以生成代码。重要的是 - 当您选择更改代码时，模型将再次反映这一点。

Windows Workflow Foundation 就是一个很好的例子。当然，后台有平面文件和/或 XML，但您通常最终会在编排工具中定义业务逻辑。这很酷！

我们需要更多的“软件工厂”思维，未来会看到更丰富的 IDE 体验，但只要计算机运行在 0 和 1 上，纯文本文件可以并且（可能）永远是一个中间阶段。正如已经有几个人所说的那样，简单的文本文件非常灵活。

score 1 · Accepted Answer

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

举个例子：如果你重命名一个方法，你的 diff/merge/source control 工具将能够告诉你只有一件事发生了变化。我们今天使用的工具会显示一长串更改，每个位置和文件调用或声明该方法。

（顺便说一下，这篇文章没有回答你可能已经注意到的问题）

score 1 · Accepted Answer

我很想知道同样的事情，如答案中所述：您希望存在什么工具/应用程序/任何东西？

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

当人们想到将源存储为文本的替代方案时，他们似乎经常会立即考虑图形表示（我在这里指的是已经可用的商业产品 - 例如 HP-vee）。如果我们看看像 FPGA 设计者这样的人的经验，我们会发现（仅）以图形方式编程是行不通的——因此像 Verilog 和 VHDL 这样的语言。

但是我不认为 source 的存储必须首先与编写它的方法绑定。来源的输入很大程度上可以作为文本完成 - 这意味着仍然可以实现复制/粘贴的问题。但我也看到，通过允许在标记化元源的基础上进行合并和回滚，我们可以实现更准确、更强大的操作工具。

score 1 · Accepted Answer

有关摒弃传统文本编程的语言示例，请参阅Lava 语言。

我最近发现的另一个好东西是subtext2（视频演示）。

score 1 · Accepted Answer

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

我看到的唯一优势是能够使用内置的 VFP 数据语言对这些文件进行代码搜索……除了它是一种责任 imo。至少每隔几个月，这些文件之一就会无缘无故地损坏。与源代码控制和差异的集成也非常痛苦。有解决方法，但涉及暂时将文件转换为文本！

score 1 · Accepted Answer

谁使用平面文件？

Eclipse 为您提供了对源代码的视图，以便我可以看到所有已排序和分组的内部类、方法和数据。如果我想编辑内部类，我点击它。虽然从技术上讲，有一个平面文件，但我几乎从不那样导航它。

score 0 · Accepted Answer

您的程序代码定义了将使用 xml 或二进制格式创建的结构。您的编程语言比 XML 或二进制表示更直接地表示您的程序结构。你有没有注意到当你给你的文档提供结构时，Word 对你的行为是如何的。WordPerfect 至少会“显示代码”以允许您查看文档下方的内容。平面文件为您的程序做同样的事情。

score 0 · Accepted Answer

好主意。我自己想知道规模更小……小得多，为什么 IDE X 不能生成这个或那个。

我不知道我作为一名程序员是否有能力开发出像你所说的或我在想的那样酷而复杂的东西，但我有兴趣尝试一下。

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

score 0 · Accepted Answer

我认为另一方面是代码才是最重要的。这就是将要执行的内容。例如，在您的 UML 示例中，我认为在您的“源 blob”中包含 UML（可能是在某些编辑器中创建，与“代码”没有直接关系）几乎是没有用的。直接从您的代码生成 UML 会更好，因此它将代码的确切状态描述为理解代码的工具，而不是作为代码应该是什么的提醒。

关于自动化文档工具，我们多年来一直在这样做。虽然实际程序员在代码中生成的注释可能与代码不同步，但 JavaDoc 等工具忠实地表示对象上的方法、返回类型、参数等。它们以实际存在的方式表示它们，而不是某些无休止的设计会议产生的人工制品。

在我看来，如果您可以任意将随机工件添加到某些“源 blob”中，那么这些可能会过时并且不会立即有用。如果您可以直接从代码中生成这样的工件，那么让您的构建过程执行此操作的小努力要比前面提到的远离纯文本源文件的陷阱要好得多。

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

score 0 · Accepted Answer

这可能无法完全回答您的问题，但这里有一个编辑器可以让您拥有更高的代码视图： http ://webpages.charter.net/edreamleo/front.html

score 0 · Accepted Answer

我认为在开发中使用文本文件的原因是它们对各种开发工具都是通用的。您可以使用简单的文本编辑器查看内部甚至修复一些错误（您不能在二进制文件中执行此操作，因为您永远不知道任何修复会如何破坏其他数据）。然而，这并不意味着文本文件最适合所有这些目的。

当然，您可以区分和合并它们。但这并不意味着 diff/merge 工具了解此文本文件编码的数据的独特结构。您可以进行差异/合并，但是（特别是在 XML 文件中看到）差异工具不会正确地显示差异，也就是说，它会显示文件不同的地方以及工具“认为”的数据部分是相同的。但它不会向您显示 XML 文件结构的差异 - 它只会匹配看起来相同的行。

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

score 0 · Accepted Answer

现代程序是由扁平的部分组成的，但它们是扁平的吗？有使用、包含和对象库等。普通的函数调用是窥探不同的地方。由于有多个线程等，逻辑并不平坦。

score 0 · Accepted Answer

我也有同样的看法！我真的希望这会存在。

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

Fortress 从一开始就被设计为具有多个句法样式表。源代码可以呈现为 ASCII 文本、Unicode 或美化图像。这将允许在渲染输出中支持数学符号和其他符号，以便于阅读。

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

score 0 · Accepted Answer

没有涉及的一件事是，某些语言在变量范围等方面具有内置源文件的概念。更改为其他内容（例如将函数存储在数据库中）将需要您更改语言本身。

score 0 · Accepted Answer

今晚和我的朋友（也是程序员）喝一杯时，其中一位告诉我他们使用 UML 来生成代码。但他表示，他们仍然需要手动编辑生成的代码，有些问题域不能用 UML 轻松描述。

有了 LINQ 的优点、lambda 等等，一些问题域不能用 UML 表示，我们仍然需要绕过生成的代码让计算机来做我们的投标。

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

这个简单问题的答案数量非常说明 UML、SQL（最重要的汇编语言，不管那些 ORM 人告诉你什么）、XML 不是 XOR 命题。我们仍将使用这些技术的组合，而不是只使用其中一种而排斥其他技术。

score 0 · Accepted Answer

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

源代码本身应该是封装为成员的面向对象的。我知道只有一种产品可以做到这一点，它存在很长时间（Windows 3.0）并且由 Paul Allen 自己设计。它最初的灵感来自 Mac 上的 Hypercard，但正如比尔盖茨所说： http: //community.seattletimes.nwsource.com/archive/ ?date=19900522&slug=1073140

“它超越了 HyperCard，”盖茨说。

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

In pursuing (interests of) software developers,'' says Alsop, Asymetrix可能让 ToolBook 对这个小家伙来说太复杂了。''

他们应该针对专业程序员而不是业余爱好者。

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

flat-file - 为什么我们仍然使用平面文件进行编程？

34 回答 34

Related

Reference