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

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

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

在我看来,某些形式的XML或二进制数据可能代表很多难以跟踪的想法,否则.

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

另一个想法是将代码评论中的注释直接嵌入到代码中.

可能有各种各样的辅助工具可以更容易地合并多个分支.

我热衷的不仅仅是跟踪代码覆盖率,还要查看自动化测试所涵盖的代码部分.困难的部分是跟踪代码,即使源被修改.例如,将一个函数从一个文件移动到另一个文件,等等.这可以通过GUID来完成,但是它们很容易嵌入到文本文件中.在丰富的文件格式中,它们可以是自动且不显眼的.

那么为什么没有IDE(据我所知,无论如何)允许你以这种方式处理代码？

编辑: 2009年10月7日.

在我的问题中,大多数人都非常喜欢"二元"这个词.我收回它.图片XML,非常简单地标记您的代码.在将其交给普通预处理器或编译器之前的那一刻,您将删除所有XML标记,并仅传递源代码.在这种形式中,您仍然可以对文件执行所有常规操作:差异,合并,编辑,在简单的最小编辑器中使用,将它们提供给数千个工具.是的,直接使用最小的XML标记进行差异,合并和编辑确实会变得更复杂.但我认为价值可能是巨大的.

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

例如,您的DOxygen注释实际上看起来像最终的DOxygen输出.

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

XML甚至可以隐藏在评论之后.

// 
// Please refactor to Delegate.
// 

然后,如果您想使用vi或emacs,您可以跳过评论.

如果我想使用最先进的编辑器,我可以通过十几种不同的有用方式看到它.

所以,这是我粗略的想法.它不是你在屏幕上拖动的图片的"构建块"......我不是那么疯狂.:)

1> davetron5000..：

---

你可以区分它们

你可以合并它们

任何人都可以编辑它们

它们简单易用

数以千计的工具可以普遍使用它们

---

"他们普遍可以使用成千上万的工具" - 宾果游戏.鸡和鸡蛋的问题,真的.

---

而且它们非常强大 - 由于升级或解析它们的程序中的其他故障,有多少次二进制文件格式被破坏了？vi损坏我的纯文本LaTeX文档的次数:0.Word损坏二进制文档结构的次数:$\infinity $.

---

这根本无法回答问题。在比较，合并或与其他工具交互之前，可以很容易地对树数据结构进行序列化。

2> Rich..：

---

在我看来,任何可能的好处都被绑定到特定工具所抵消.

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

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

3> jop..：

---

Smalltalk是一个基于图像的环境.您不再使用磁盘上的文件中的代码.您正在运行并修改运行时的实际对象.它仍然是文本,但类不存储在人类可读文件中.相反,整个对象存储器(图像)以二进制格式存储在文件中.

但尝试使用smalltalk的人最大的抱怨是因为它不使用文件.我们拥有的大多数基于文件的工具(vim,emacs,eclipse,vs.net,unix工具)将不得不放弃使用smalltalk自己的工具.并不是说在smalltalk中提供的工具不如.这是不同的.

4> yfeldblum..：

---

为什么论文是用文字写的？为什么法律文件用文字写成？为什么幻想小说用文字写成？因为文本是持久化思想的唯一最佳形式 - 对于人们而言.

文本是人们如何思考,表达,理解和坚持概念 - 以及它们的复杂性,层次结构和相互关系.

---

这根本不是真的.有些东西最好用图表来描述.想想流程图:采用流程图,您可以创建它的文本表示,但它更容易理解为图表.

---

尼克,我不同意; 伪代码通常是显示算法而不是流程图的更清晰的方式.像循环这样的东西不能直接在流程图中表示,所以当你读它时你必须弄清楚哪些位实际上是一个循环等.

---

大多数研究论文以PS或PDF格式发布,而不是ASCII格式.你的表达与表达混淆.丰富格式的图表非常有用 - 更不用说方程式的精美表示了.

---

我认为问题是关于平面文件而不仅仅是关于文本的使用.

5> sanxiyn..：

---

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

---

我是一个日常的Lisper,我不得不在某种程度上不同意你.Lisp源代码包含许多在解析时未保留的信息 - 例如读者宏和注释.您还可以说C源代码是C编译器的解析树的序列化.

6> Mark Stock..：

---

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

7> Pitarou..：

---

这是一个很好的问题.FWIW,我很想看到一个Wiki风格的代码管理工具.每个功能单元都有自己的维基页面.构建工具将源代码整合到Wiki中.会有一个链接到该页面的"讨论"页面,人们可以在这里讨论算法,API等.

哎呀,从预先存在的Wiki实现中破解一个并不难.任何接受者......？

8> Edu Felipe..：

---

原因如下:

人类可读.在文件和解析方法中,这更容易发现错误.也可以大声朗读.这是您无法使用XML获得的,并且可能会有所作为,特别是在客户支持方面.

保险免于过时.只要正则表达式存在,就可以在几行代码中编写一个非常好的解析器.

杠杆.从修订控制系统到编辑器到过滤器,几乎所有内容都可以检查,合并和操作平面文件.合并XML可能是一团糟.

能够使用UNIX工具轻松集成它们,例如grep,cut或sed.

9> Jon Limjap..：

---

具有讽刺意味的是,编程结构正是使用您所描述的内容.

例如,SQL Server Integration Services(通过将组件拖动到可视设计图面中来编写逻辑流程)将保存为精确描述该后端的XML文件.

另一方面,SSIS很难进行源代码控制.设计任何类型的复杂逻辑也是相当困难的:如果你需要更多的"控制",你需要将VB.NET代码编码到组件中,这将我们带回到我们开始的地方.

我想,作为一名程序员,您应该考虑这样一个事实:对于问题的每个解决方案都会产生后果.并非一切都可以(有些人认为应该)用UML表示.不是所有东西都可以用视觉表现 并非所有内容都可以简化为具有一致的二进制文件表示.

话虽这么说,我认为将代码降级为二进制格式(其中大多数也倾向于专有)的缺点远远超过了以纯文本格式使用它们的优点.

10> Mark Cidade..：

---

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

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

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