把代码储存到可查询数据结构中？

目前使用平面文件这一主流是否就是表示代码的最佳方法呢？ Rick Minerich 的帖子提倡远离这个模式，Blogspace 中已经对此有所反应、出现了一些讨论。

他指出，在平面文件中描述代码不允许用最恰当的方式组织代码。函数或类在文件中的顺序、程序的文件夹组织都依赖于程序员随意的选择，并反映出他们对代码组织和其含义表达的想法。但是，“没有两个程序员的想法是完全一样的”，而且源码一牵扯到多个作者，结构就会有被修改的风险，这样在所有的层次上，文件里的代码结构、程序的文件夹结构，以及两者之间的关系都可能失去一致性。

尽管有减少这些风险的解决办法——比如将内容分散到尽可能多的文件中、划分出代码边界——但 Rick Minerich 认为这些解决办法仅仅部分回答了他提出的问题，因为“平面文件是问题的根源。”

此外，在一些情况下，代码的组织依照“特定任务可以有不同的排序 / 含义 [……]”，但为每个单独的任务重新组织由平面文件描述的代码却是难以想象的。

为了回答这些问题，Rick 提倡用另一种办法来表示代码：

如果你能把代码的呈现方式看作一种抽象的数据结构，那你为什么不干脆把源码本身保存在一种类似抽象数据结构中呢？程序的结构不是更像图而非列表吗？

[……]

如果我们把代码保留在可查询的数据结构中，用我们选择的任意方式来设置环境会比较容易。[……] 比如说，你可以显示一个方法和一切引用它的内容。代码可视化的可能性是无限的。

[……]

远离平面文件的真正方便之处在于，我们可以选择的任意方式可视化程序结构，我们将从中获得的效率和理解。

Rick 的帖子引起了很多反应。 Steve Hawley 分享了他的观点，还提议使用 LINQ 来支持查询式的代码组织方式：

【在这样的组织方式下，】在编译一行代码时，断定正在处理哪些变量的过程实际上是一种数据库查询，这一点给我留下了深刻的印象。作用域及其语义都是查询（以及数据库结构）的一部分。

另外，完成编译的实际链接（无论该链接是在构建时还是在运行时完成的）又是一个查询。

编译的过程实际上就是构建一个数据库的过程。

但是，一些评论者提醒注意一个事实，即这种代码组织方式是已经存在的。比如 Keith Braithwaite 认为，“Rick Minerich 所说的合理的结论应该是一种基于映像的（image-based）环境”，实际上在 Smalltalk 和 Lisp 中已经有这样的东西了。除了 Smalltalk 之外，另一位评论者给出了 VisualAge Suite 的例子，在 VisualAge Suite 中，“所有的代码都储存在一个代码数据库中 [……]，你可以用你需要的任何方式进行查询”。

然而，Steve Hawley 和其他几个博客强调不应该否认使用平面文件的好处。平面文件有利于浏览代码，因为人类“很在意空白和事物的相对位置，平面文件能很好地满足这种要求”。人们能“建立起对布局的熟悉，下意识就能非常高效地导航到文件中正确的位置”。

在 Reddit 上的讨论中，有一则评论主张，一些 Rick Minerich 认为是平面文件缺陷的地方也可以被视为优点，比如任意的结构就有其好处，因为定义结构的过程中，可以利用其灵活性来表达意图：

像运算符之间的空格数量这样的东西也有很好的用途，比如连续多行意义相似的代码，可以调整空格数量让它们对齐，以凸显它们之间的关系。可以调整函数的顺序来达到叙述的效果。人们在使用手头的工具来书写有表现力的代码方面非常有创造性。如果你打算换一种代码组织形式，我希望能有一个好的理由让我相信这种替代物能达到同样的效率。

Keith Braithwaite 提醒大家注意这样一个事实，远离平面文件表示也意味着告别文本编辑器和版本控制工具，而且他认为程序员还不准备付出这种代价。另一位评论者JSJ 认为基于映像的格式还会使更多工具无法使用，他强调“只需构建一套工具，就能在全部（或大部分）编程语言中使用”的能力“是平面文件的一项巨大优势”。

Rick Minerich 自己也提出了工具化的问题，他认为平面文件仍被使用的其中一个原因就在于，所有工具都是为用平面文件来组织代码而设计的。比如说，几乎所有的编译器都要有完整的程序代码才能编译。他相信“对于将代码保存在抽象的数据结构中这一研究来说，一种与传统编译和链接无关的语言将是理想的研究基础”。他建议对于基于查询的代码组织方式，第一步的解决办法是：

良好的第一步应该是有一个 IDE 或编辑器，它能在数据库中管理所有的代码，并允许程序员动态地创建查询语句来构建视图、用不同的方式操作代码。然后该环境还可以生成平面文件，以达到与当前编译器兼容。

查看英文原文： Storing Code in Queryable Data Structures?