为什么平面文本文件是表示源代码的最新技术？
当然 - 预处理器和编译器需要查看文件的平面文件表示，但这很容易创建。
在我看来，某些形式的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，你可以跳过评论。
如果我想使用最先进的编辑器，我可以通过十几种不同的有用方式看到它。
所以，这是我粗略的想法。它不是你在屏幕上拖动的图片的“构建块”......我不是那么疯狂。 ：）
答案 0 :(得分：138)
答案 1 :(得分：25)
在我看来，与特定工具捆绑在一起可能会超过任何可能的好处。
使用纯文本源（这似乎是您正在讨论的内容，而不是平面文件本身）我可以将块粘贴到电子邮件中，使用简单的版本控制系统（非常重要！ ），将代码写入Stack Overflow的注释中，在任意数量的平台上使用一千个文本编辑器等。
使用代码的二进制表示，我需要使用专门的编辑器来查看或编辑它。即使可以生成基于文本的表示，也不能轻易地将更改回滚到规范版本。
答案 2 :(得分：14)
Smalltalk是一个基于图像的环境。您不再使用磁盘上的文件中的代码。您正在运行并修改运行时的实际对象。它仍然是文本，但类不存储在人类可读文件中。相反，整个对象存储器（图像）以二进制格式存储在文件中。
但那些尝试使用smalltalk的人最大的抱怨是因为它不使用文件。我们拥有的大多数基于文件的工具（vim，emacs，eclipse，vs.net，unix工具）将不得不放弃使用smalltalk自己的工具。并不是说在smalltalk中提供的工具不如。这是完全不同的。
答案 3 :(得分：11)
为什么论文是用文字写的？为什么法律文件用文字写成？为什么幻想小说用文字写成？因为文本是持久化思想的唯一最佳形式 -
文字是人们如何思考，表达，理解和坚持概念 - 以及它们的复杂性，层次结构和相互关系。
答案 4 :(得分：10)
Lisp程序不是平面文件。它们是数据结构的序列化。这种代码作为数据是一个古老的想法，实际上是计算机科学中最伟大的想法之一。
答案 5 :(得分：9)
＆lt;？xml version =“1.0”encoding =“UTF-8”？＆gt;＆lt; code＆gt;平面文件更易于阅读。＆lt; / code＆gt;＆lt; / xml＆gt;
答案 6 :(得分：7)
原因如下：
人类可读。在文件和解析方法中，这更容易发现错误。也可以大声朗读。这是您无法使用XML获得的，并且可能会有所帮助，特别是在客户支持方面。
防止过时的保险。只要正则表达式存在，就可以在几行代码中编写一个非常好的解析器。
杠杆。从修订控制系统到编辑器到过滤器，几乎所有内容都可以检查，合并和操作平面文件。合并XML可能是一团糟。
能够轻松地将它们与UNIX工具集成，例如grep，cut或sed。
答案 7 :(得分：6)
这是一个很好的问题。 FWIW，我很想看到一个Wiki风格的代码管理工具。每个功能单元都有自己的维基页面。构建工具将源代码整合到Wiki中。会有一个链接到该页面的“讨论”页面，人们可以在这里讨论算法，API等。
哎呀，从预先存在的Wiki实现中攻击一个并不难。任何人......？
答案 8 :(得分：5)
具有讽刺意味的是，有些编程结构正好使用了你所描述的内容。
例如，SQL Server Integration Services涉及通过将组件拖动到可视设计图面来编写逻辑流程，将其保存为精确描述该后端的XML文件。
另一方面，SSIS很难进行源代码控制。设计任何类型的复杂逻辑也是相当困难的：如果你需要更多的“控制”，你需要将VB.NET代码编码到组件中，这会将带回来到我们开始的地方。
我想，作为一名程序员，您应该考虑这样一个事实：对于问题的每个解决方案都会产生后果。并非一切都可以（有些人认为应该）用UML表示。不是所有东西都可以用视觉表现并非所有内容都可以简化为具有一致的二进制文件表示。
话虽如此，我认为将代码降级为二进制格式（其中大部分也倾向于专有）的缺点远远超过了以纯文本形式使用它们的优势。
答案 9 :(得分：4)
答案 10 :(得分：4)
人们已经尝试了很长时间来创建一个超出平面文件的编辑环境，并且每个人都在某种程度上失败了。我见过的最接近的是查尔斯·西蒙尼的故意编程的原型，但后来被降级为可视化DSL创建工具。
无论代码如何在内存中存储或表示，最终它必须是可呈现的并且可以修改为文本（没有格式化更改），因为这是我们所知道的最简单方式表达通过编程解决问题所需的大部分抽象概念。
对于平面文件，您可以免费获得此文件，任何普通的旧文本编辑器（具有正确的字符编码支持）都可以使用。
答案 11 :(得分：4)
史蒂夫麦康奈尔一如既往地做对了 - 你为其他程序员（包括你自己）编写程序，而不是为计算机编写程序。
也就是说，Microsoft Visual Studio必须在内部管理您以非常结构化的格式编写的代码，否则您将无法执行“查找所有引用”之类的内容，或者很容易重命名或重新调整变量和方法的因素。如果有人知道这是如何工作的，我会感兴趣。
答案 12 :(得分：4)
实际上，大约10年前，查尔斯·西蒙尼（Charles Simonyi）早期的故意编程原型试图将平面文件转移到可以以不同方式可视化的代码树表示中。从理论上讲，领域专家，PM和软件工程师都可以以对他们有用的方式看待（并拼凑）应用程序代码，并且可以在声明性“意图”的层次结构上构建产品，挖掘到低 - 仅在需要时使用级别代码。
ETA（问题中的每个请求）Microsoft研究网站上有one of his early papers的副本。不幸的是，由于Simonyi几年前离开MS成立了一家独立的公司，我认为原型仍然无法下载。我在微软时看到了一些演示，但我不确定他早期原型的分发范围有多广。
他的公司IntentSoft对于他们计划向市场推出的产品仍然有点安静，如果有的话，但MSR产生的一些早期产品非常有趣。
存储模型是一些二进制格式，但我不确定在MSR项目中有多少这些细节被披露，我确信自早期实施以来有些事情已经发生了变化。
答案 13 :(得分：3)
Labview和Simulink是两个图形编程环境。它们在各自的领域都很流行（分别与PC的硬件接口和建模控制系统），但在这些领域之外并没有太多使用。我和两个都是粉丝的人一起工作过，但我自己也从不接触过它们。
答案 14 :(得分：3)
为什么文本文件会统治？因为麦克罗伊的考验。让一个程序的输出作为另一个程序的源代码是可接受的至关重要，而文本文件是最简单的工作。
答案 15 :(得分：2)
你提到我们应该使用“某种形式的XML”吗？您认为XHTML和XAML是什么？
XML也只是一个平面文件。
答案 16 :(得分：2)
有人试过Mathematica吗？
上面的图片来自一个旧版本，但它是最好的谷歌可以给我。
无论如何......将第一个等式与 Math.Integrate（1 /（Math.Pow（“x”，3）-1），“x”）进行比较，就像你需要的那样如果您使用大多数常见语言的纯文本编码，请写。 Imo数学表示更容易阅读，这仍然是一个非常小的等式。
是的，如果需要，您可以将代码作为纯文本输入和复制粘贴。
将其视为下一代语法突出显示。我敢打赌，除了数学之外还有很多其他东西可以从这种表现中获益。
答案 17 :(得分：2)
我想，老习惯会变得很难。
直到最近，没有很多高质量，高性能，广泛可用的库用于结构化数据的一般存储。而且我强调不即使在今天也将XML放在该类别中 - 太冗长，过于密集而无法处理，太挑剔。
如今，我最喜欢使用的数据不需要人类可读SQLite并创建数据库。将功能齐全的SQL数据库嵌入到任何应用程序中都非常容易......有C，Perl，Python，PHP等的绑定......它是开源的，非常快速，可靠，轻量级。
我＆lt; 3 SQLite。
答案 18 :(得分：1)
Visual FoxPro使用dbf表结构来存储表单，报表，类库等的代码和元数据。这些是二进制文件。它还将代码存储在实际文本文件的prg文件中......
我看到的唯一优势是能够使用内置的VFP数据语言对这些文件进行代码搜索......除此之外，它还是一个负担。至少每隔几个月，其中一个文件会因为没有明显原因而被破坏。与源代码控制集成并且差异非常痛苦。有解决方法，但涉及暂时将文件转换为文本！
答案 19 :(得分：1)
我们看到的关于DSL的趋势是在阅读您的问题时首先想到的。问题在于模型（如UML）和实现之间不存在一对一的关系。微软和其他人正在努力实现这一目标，因此您可以将您的应用程序创建为类似UML的东西，然后可以生成代码。重要的是 - 当您选择更改代码时，模型将再次反映这一点。
Windows Workflow Foundation就是一个很好的例子。原因是后台有平面文件和/或XML，但通常最终会在业务流程工具中定义业务逻辑。这很酷！
我们需要更多的“软件工厂”思考，并且将来会看到更丰富的IDE体验，但只要计算机以0和1运行，平面文本文件就可以（并且可能）始终处于中间阶段。如前所述，简单的文本文件非常灵活。
答案 20 :(得分：1)
有关不使用传统文本编程的语言示例，请参阅Lava Language。
我最近发现的另一件好事是subtext2（video demo）。
答案 21 :(得分：1)
我非常想知道同样的事情，如答案所述： What tool/application/whatever do you wish existed?
虽然很容易想象出很多好处，但我认为必须解决的最大障碍是没有人能够提供可行的替代方案。
当人们想到将源代码存储为文本的替代方案时，他们似乎经常会立即考虑图形表示（我在这里指的是已经可用的商业产品 - 例如HP-vee）。 如果我们看一下像FPGA设计师这样的人的经验，我们会看到编程（专门）只是图形化不起作用 - 因此像Verilog和VHDL这样的语言。
但是我没有看到源的存储必然需要首先绑定到编写它的方法。 源的输入可以在很大程度上以文本形式完成 - 这意味着仍然可以实现复制/粘贴的问题。 但我也看到，通过允许在标记化元源的基础上完成合并和回滚，我们可以实现更准确，更强大的操作工具。
答案 22 :(得分：1)
很明显为什么纯文本是王道。但同样明显的是，为什么结构化格式会更好。
仅举一个例子：如果重命名方法，你的差异/合并/源代码控制工具就能告诉你只有一件事发生了变化。我们今天使用的工具会显示一长串的更改，一个用于调用或声明方法的每个位置和文件。
（顺便说一下，这篇文章没有回答你可能已经注意到的问题）
答案 23 :(得分：0)
这可能无法完全回答您的问题，但这里的编辑器允许更高的代码视图： http://webpages.charter.net/edreamleo/front.html
答案 24 :(得分：0)
我认为在开发中使用文本文件的原因是它们对各种开发工具都是通用的。您可以使用简单的文本编辑器查看内部甚至修复一些错误（您无法在二进制文件中执行此操作，因为您永远不知道任何修复将如何破坏其他数据）。但是，这并不意味着文本文件最适合所有这些目的。
当然，您可以对它们进行区分和合并。但这并不意味着diff / merge工具理解由该文本文件编码的数据的不同结构。您可以执行diff / merge，但是（特别是在XML文件中看到）diff工具不会正确显示差异，也就是说，它会显示文件的不同之处以及工具“认为”的数据部分是相同的。但它不会向您展示XML文件结构的差异 - 它只会匹配看起来相同的行。
无论我们是使用二进制文件还是文本文件，差异/合并工具总是更好地处理此文件所代表的数据结构，而不是行和字符。例如，对于C ++或Java文件，报告某些标识符更改了其名称，报告某些部分被其他if（）{}包围，但另一方面，忽略缩进或EOL字符的更改。最好的方法是将文件读入内部结构并使用特定格式规则转储。这样，差异将通过内部结构进行，合并结果将从合并的内部结构生成。
答案 25 :(得分：0)
我认为这方面的另一个方面是代码是重要的。它将被执行。例如，在你的UML示例中，我认为而不是让你的“源代码blob”中包含的UML（可能是在某些编辑器中创建，与“代码”没有直接关系）几乎是无用的。更好的方法是直接从代码生成UML，因此它描述了代码所处的确切状态，作为理解代码的工具，而不是提醒代码应该是什么。
多年来，我们一直在使用自动化doc工具。虽然代码中的实际程序员生成的注释可能与代码不同步，但像JavaDoc等工具忠实地表示对象上的方法，返回类型，参数等。它们代表它们实际存在，而不是某些无休止的设计会议产生的神器。
在我看来，如果你可以随意地将随机工件添加到某些“源blob”中，这些可能会过时而且不太有用。如果你可以直接从代码中生成这样的工件，那么让你的构建过程这么做的微小工作远比前面提到的远离纯文本源文件的陷阱要好得多。
与此相关，explanation of why you'd want to use a plain-text UML tool（UMLGraph）似乎也适用于您想要纯文本源文件的原因。
答案 26 :(得分：0)
现代节目由扁平片组成，但它们是扁平的吗？有使用，包括和对象库等。普通的函数调用是窥视不同的地方。由于有多个线程等，逻辑并不平坦。
答案 27 :(得分：0)
干净的想法。我自己想知道规模较小......更小，为什么IDE X不能生成这个或那个。
我不知道我是否有能力作为一名程序员开发像你所说的那样酷或复杂的东西，或者我正在考虑的东西，但我会有兴趣尝试。
也许从.NET，Eclipse，Netbeans等的一些插件开始？展示可以做什么，并开始编码的新趋势。
答案 28 :(得分：0)
我有同样的愿景！我真的希望这会存在。
你可能想看看Sun的研究语言Fortress。它对源代码中的公式有特殊支持。以下引用来自维基百科
Fortress正在设计中 开头有多个句法 样式表。源代码可以 呈现为ASCII文本，Unicode或 作为一个漂亮的形象。这将允许 用于支持数学符号 和渲染中的其他符号 输出更容易阅读。
文本作为源持续存在的主要原因是缺少powertools，例如版本控制，用于非文本日期。这是基于我使用Smalltalk的经验，其中普通字节码始终保存在核心转储中。在非文本系统中，使用今天的工具，团队开发是一场噩梦。
答案 29 :(得分：0)
程序代码定义了使用xml或二进制格式创建的结构。与XML或二进制表示形式相比，您的编程语言更直接地表示程序的结构。当你为文档提供结构时，你有没有注意到Word是如何对你行为不端的？ WordPerfect至少会“显示代码”，以便您查看文档下方的内容。平面文件为您的程序执行相同的操作。
答案 30 :(得分：0)
谁使用平面文件？
Eclipse为您提供了源代码的视图，以便我可以看到内部类，方法和数据，所有内容都被排序和分组。如果我想编辑内部类，我点击它。虽然在技术上有一个平面文件，我几乎从来没有像那样导航它。
答案 31 :(得分：0)
有一点未涉及的是，某些语言具有内置于变量作用域等内容的源文件的概念。更改为其他内容（如在数据库中存储函数）将需要您更改语言本身。
答案 32 :(得分：0)
今晚和我的朋友（程序员）喝酒时，其中一人告诉我他们使用UML来生成代码。但是他说他们仍然需要手动编辑生成的代码，有一些问题域用UML不能轻易描述。
由于所有LINQ-goodness，lambda和所有，一些问题域都无法用UML表示，我们仍然需要绕过生成的代码让计算机进行我们的出价。
我们怎样才能在UML中代表XML，更不用说XML，以下问题？ LINQ to SQL using GROUP BY and COUNT(DISTINCT)
这个简单问题的答案数量非常明确，UML，SQL（最重要的汇编语言，无论那些ORM人员告诉你什么），XML都不是XOR主张。我们仍将使用这些技术的组合，而不仅仅使用其中一种技术来排除其他技术。
答案 33 :(得分：0)
它仍然是平面文件，因为这可能就是他们如何销售软件工具：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之外，它仍然超越其他语言;）
