如何管理编译器项目?

发布于 2024-08-05 21:08:58 字数 1436 浏览 4 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

妖妓 2024-08-12 21:08:58

您还没有真正指定您正在编译的内容,因此提出具体建议有点困难。

如果您正在做一些新颖的事情,我几周前写了一篇博客文章,其中有一些需要考虑的具体事项:

http://www.plsadventures.com/2009/09/why-programming-language-design-is-hard.html

如果是如果您正在编译一个预先存在的语言,那么我将努力生成一个像样的测试语料库,并考虑使用测试驱动开发来管理您的进度。

正如您所提到的,大多数编译器中有一些明显的相对离散的组件。我会考虑记录连接这些组件的接口。例如,如果一个人正在编写词法分析器,另一个人正在编写解析器,那么请确保您在某处写下了一个标记列表。应该定义并写下解析和/或抽象语法树的格式,以便任何从事优化或代码生成工作的人都在同一页面上。

最重要的是,测试确实有助于这种集成。大多数情况下,您应该能够单独构建这些组件并将它们组合在一起。

You haven't really specified what it is that you are compiling, so it's a little difficult to make specific recommendations.

If you're doing something novel, I wrote a blog post a couple of weeks ago that has some specific things to consider:

http://www.plsadventures.com/2009/09/why-programming-language-design-is-hard.html

If it is a pre-existing language you are compiling, then I would work to generate a decent test corpus, and consider using test-driven development to manage your progress.

As you mentioned, there are some obvious components in most compilers that are relatively discrete. I would consider documenting the interfaces that connect these components. For example, if one person is writing the lexer and another is writing the parser, then ensure that you have a list of tokens written down somewhere. The format for your parse and/or abstract syntax trees should be defined and written down so that anybody working on optimisation or code generation is on the same page.

Above all, tests really help this kind of integration. You should be able to build these components separately and put them together, for the most part.

寒江雪… 2024-08-12 21:08:58

您应该使用像 Git 或 Mercurial 这样的 DCVS,这样每个人都可以单独开发,同时仍然可以轻松地合并更改。

接下来,您应该定义测试用例,以了解您需要哪些功能以及如何知道某个功能的工作原理。

这应该有助于找出项目中没有太多重叠的不同领域,这样团队的每个成员都可以在不互相干扰的情况下工作。

You should use a DCVS like Git or Mercurial, so each of you can develop individually while it's still easy to merge changes.

Next, you should define test cases to know which features you'll need and how you will know that a feature works.

That should help to figure out different areas of the project which don't overlap too much so each member of the team can work without stepping on each others toes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文