logo标签列表

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

flat-file
49
为什么纯文本文件是代表源代码的最先进技术？
当然 - 预处理器和编译器需要看到文件的平面表示，但这很容易创建。
在我看来，某种形式的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，你可以直接跳过注释。

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

这就是我的大致想法。它不是“图块”形式的，你可以拖动它们到屏幕上...我并不疯狂。 :)

这里很多回答都混淆了表示和呈现。当你打开一个MS Word文档时，你仍然在编辑文本，只不过它是二进制格式。而且之所以diff / merging如此困难，部分原因是平面文件无法向你解释进行了哪些重构。 - Matt Cruikshank
有一种基于多媒体的编程语言叫做 Max/MSP，它使用可视化节点而非文本。 - Max Cantor
如果有什么我想避免的事情，那就是写更多的XML。你所描述的新功能可以通过分析某种方式下的普通源代码的工具来完成（实际上，在某个地方已经被完成了）。 - TM.
@TM - 我并不是在暗示人类会编写XML。它只是以那种方式存储在文本文件中。 - Matt Cruikshank
源代码不是平面的。它代表了一棵解析树。 - Christoffer Hammarström
显示剩余5条评论
34个回答
141
  • 你可以对它们进行比较(diff)
  • 你可以将它们合并(merge)
  • 任何人都可以编辑它们
  • 它们简单易处理
  • 成千上万的工具都可以普遍地访问它们
没有人拥有这个格式。 - Jeff Yates
17
“它们普遍适用于成千上万的工具” - 好极了。这其实是一个鸡生蛋或蛋生鸡的问题。 - Bernard
这一切都与源代码控制有关，伙计！ - Richard Morgan
你可以像比较文本文件中的行一样轻松地在内存中比较树节点。尽管最大的优势是您可以更轻松地忽略差异中的格式和注释。但是，是的，鸡生蛋的问题仍然存在。 - Dominik Grabiec
2
这根本没有回答问题。一棵树形数据结构在差异分析、合并或与其他工具交互之前，同样可以进行序列化。 - Jonathan Tran
9
它们非常健壮--二进制文件格式由于程序升级或其他解析问题而破坏了多少次？Vi损坏我的纯文本LaTeX文档的次数：0。Word损坏二进制文档结构的次数：$\infty$。 - Hudson
25

在我看来，任何可能的好处都被绑定到了特定工具上这一点所抵消。

使用纯文本源代码（似乎你讨论的是它，而不是单独的文件），我可以将代码块粘贴到电子邮件中，在Stack Overflow的评论中编写代码，使用数千种文本编辑器在各种平台上编辑代码等等（非常重要的是，可以使用简单的版本控制系统！）。

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

最终您仍需要专业的工具：编译器。所有的东西，比如合并纯文本都会导致代码错误。这种方法不起作用，我们已经在尝试将编译器/代码完成功能直接集成到 diff/merge 工具中了。 - Evgeny Gorbovoy
14

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

但尝试使用Smalltalk的人最大的抱怨是它不使用文件。我们拥有的大多数基于文件的工具（如vim、emacs、eclipse、vs.net、unix工具）都必须被放弃，改用Smalltalk自己的工具。并非小谈提供的工具比其他工具差。只是不同而已。

Smalltalk是实时解释执行的吗？ - Jon Limjap
Squeak Smalltalk是解释执行的。其他Smalltalk语言则被编译成字节码。 - jop
你确定Squeak是解释执行的吗？ 运行(Number>>#asInteger) inspect会在一个CompiledMethod上打开一个Inspector，你可以看到字节码。 - Sébastien RoccaSerra
“http://www.squeak.org/Features/”将“interpreted”列为其特性之一。但现在我很好奇这实际上是什么意思。是否编译成字节码，然后由虚拟机解释执行？我知道VisualWorks也会编译成字节码，但它有一个JITter。不确定Squeak是否也是如此。 - jop
一些“解释型”语言（例如CPython）实际上被编译成非常高级的字节码：http://docs.python.org/library/dis.html#python-bytecode-instructions - skymt
11
为什么文章、法律文件和幻想小说都是用文本形式写成的呢？因为对于人们来说，文本是最好的表达思想并将其保留下来的形式。文本是人们思考、描述、理解和保存概念及其复杂性、层次结构和相互关系的方式。
8
完全不是那样的。有些事情最好用图表来描述。想想流程图：你可以创建一个文本表示的流程图，但作为图表更容易理解。 - nickf
2
我认为这个问题涉及到平面文件，而不仅仅是关于文本的用法。 - jop
4
我不同意，伪代码通常比流程图更清晰地展示算法。例如，像for循环这样的内容无法直接在流程图中表示，因此当你阅读流程图时，你必须得弄清哪些部分实际上是一个循环等等。 - Mark Baker
3
大多数研究论文都是以PS或PDF格式发布的，不是ASCII。你混淆了表示和呈现。富格式中的图表非常有帮助 - 更不用说方程式的漂亮呈现了。 - Matt Cruikshank
11

Lisp程序不是平面文件。它们是数据结构的序列化。这种代码即数据的思想已经存在很久了，实际上是计算机科学中最伟大的想法之一。

我猜这些想法还没有跟上时代 :) - jop
4
我是一名日常使用Lisp的程序员，我不完全同意你的观点。Lisp源代码包含了很多在解析时无法保留的信息，例如阅读器宏和注释。你也可以说C语言源代码是C编译器解析树的序列化表现形式。 - Rich
我必须同意Rich的观点——所有计算机语言都提供了一些解析树的深度。Lisp之所以伟大，是因为它清晰地表达了这个概念，并且程序能够在它们自己的解析树上工作。 - Svante
8

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

7

这是一个好问题。就我而言，我希望看到一种类似Wiki的代码管理工具。每个功能单元都有自己的维基页面。构建工具从维基中提取源代码。还会有一个“讨论”页面与该页面链接，人们可以在上面讨论算法、API等。

实际上，从现有的Wiki实现中对其进行修改并不难。有人愿意来尝试吗？

看起来很不错的是，因为代码是以纯文本形式存储的，所以编写一个能够实现这一点的维基系统并不难。如果代码是以某种预定义结构的 XML 形式存储的话，这将会更加困难，而且很可能根本无法实现。 - Orion Edwards
这可以成为分析和设计阶段的一部分，并且是规格和实际代码的后续步骤。 - slashmais
7
这就是原因：

  • 可读性高。这可以更容易地发现文件和解析方法中的错误。还可以大声朗读。这是XML所不能做到的，可能会在客户支持方面有所不同。

  • 免受过时影响。只要正则表达式存在，就可以用几行代码编写一个相当不错的解析器。

  • 利用优势。几乎所有的东西都可以从版本控制系统到编辑器再到筛选器检查、合并和操作平面文件。合并XML可能会很混乱。

  • 能够很容易地与UNIX工具集成，例如grep、cut或sed。

1
有些语言不能用这种方式进行解析（例如 C++）。 - Paweł Hajdan
5
具有讽刺意味的是，确实存在使用您所描述的内容的编程结构。
例如，SQL Server Integration Services（涉及通过将组件拖入可视化设计界面来编写逻辑流的编码）保存为描述后端的XML文件。
另一方面，SSIS相当难以进行源代码控制。它也相当难以设计任何复杂的逻辑：如果您需要更多“控制”，则需要在组件中编写VB.NET代码，这使我们回到了起点。
我想，作为程序员，您应该考虑到解决问题的每个解决方案都会产生后果。并非所有内容都可以（有人认为不应该）用UML表示。并非所有内容都可以以视觉方式表示。并非所有内容都可以简化到具有一致的二进制文件表示。
话虽如此，我认为将代码归为二进制格式（其中大部分还倾向于专有）的缺点远远超过将其放在纯文本中的优点。
好的，那么让我把 <img src="UMLDiagram.png"> 放到我的注释中，并让IDE聪明到足以显示该图像。这仍然只是文本。没有魔法。只是IDE现在太愚蠢了无法做到。 - Matt Cruikshank
或者更好的是，让我嵌入像Google Chart API对象这样的东西，所有的注释都很聪明，让IDE解决并显示它。天哪，IDE至少应该理解DOxygen注释，并且像DOxygen输出一样聪明和可导航！！！ - Matt Cruikshank
自己编写DOxygen解析器，也许是个好主意？我们在谈论哪些IDE呢？ - Jon Limjap
等待VS10，然后自己编写 :) - Simon Buchan
5
很长一段时间以来，人们一直试图创建一个超越平面文件的编辑环境，但每个人都在某种程度上失败了。我看到的最接近的是Charles Simonyi的意图编程原型，但后来它被降级为可视化DSL创建工具。
无论代码如何存储或在内存中表示，最终都必须呈现为文本并可修改（而不会更改格式），因为这是我们了解大多数需要通过编程解决问题的抽象概念的最简单方式。
使用平面文件，您可以免费获得此功能，并且任何普通的文本编辑器（具有正确的字符编码支持）都可以使用。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接