BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Sadek Drobi 关注 0 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2008年6月28日. 估计阅读时间: 5 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

目前使用平面文件这一主流是否就是表示代码的最佳方法呢?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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

回复 by 郭 东

论题很好
还有一个问题是文件比较直接,假设是脚本文件,紧急时候很容易更改,而存放数据库的话,你必须保证工具能使用。这和log 不存放数据库类似

想法很好 by Wu Junyin

只是不一定要考虑用数据库而已,可以考虑其他的构成方式,然后提供一个可以导入导出文本文件的工具,关注中……

LEO 可算是这样的 IDE by Super Lynx

LEO 这个“文学编程工具”自身将所有东西存储在 .leo XML 文件里,
支持导出和导入平面文件

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT