编程时,我会累积代码片段和实用程序类。我希望将它们存储起来以备将来使用。
简单问题是,最好的方法是什么。更详细的例子:
编写代码时,我们不断重复使用我们的好花絮来涵盖常见任务。然而,为了使我们的项目开源,比如使用github上的git,这个花絮也需要可用。我想知道如何最好地做到这一点。
与所有公共代码一样,这样的代码片段应该轻巧,快速,经过测试,可移植,有文档记录,最好是相对自包含的。现在我在某个地方找到了这个漂亮的代码并且它使用了CTASSERT,这是不可移植的。
我该怎么办?
我期待着听到你如何解决这个问题,以及一般的想法和指导方针。
答案 0 :(得分:1)
在这方面似乎没有什么animo,但我仍然对它非常兴奋并希望得到别人的意见。这就是我想出的:
<强>动机强>
每个程序员都会积累一堆可重复使用的代码片段。然而,大多数情况下,这些片段最终会出现在项目的全局头文件中,然后将它们复制/粘贴到新项目中。
这有一些缺点。代码是笨拙的,它通过适当的单元测试和开发演变而被拒绝了它自己的生命。此外,这导致几个相似或相同的代码副本在没有基础设施的情况下挥之不去,以便立即维护它们。
任何公开发布的代码都需要代码段符合标准并经过全面测试。
实施
我发现可以使用git中的代码段库创建一个很好的解决方案。我创建的所有未来项目都可以将此库作为子模块,单个片段也是该库的子模块。用户可以选择仅下载他们使用的那些片段,同时享受所有的中央包含目录,以及对文档和单元测试的集中访问。
我有一个TidBits_Cpp存储库。此存储库包含每个代码段的子模块。
主要的repo有一个include目录,就像boost一样,只是中心目录中的includes只包含来自子目录的其他文件,每个tidbit只有一个,如果你想使用那个tidbit,你需要的那个。它们将子目录包含在名称空间的tidbits中。保持子模块的命名空间允许其他人将这些片段包含在他们自己的片段库中,并在它们周围添加自己的命名空间。
每个带有代码段的子模块主要是仅包含标头的实现,带有用于单元测试的标头,以及一个独立的单元测试应用程序。
单元测试基类也是TidBit。主仓库有一个单元测试应用程序,用于测试系统中存在的所有TidBits。为此,它有一个带有虚拟包含的目录,它应该是包含路径中的最后一个,所以你总是可以编译。检查定义允许知道哪些代码实际可用于单元测试。
子模块中的所有代码都假定中心包含目录位于包含路径中。
存储库中包含DoxyFiles以及visual studio解决方案。 Eclipse更难,因为它与使用来自不同目录的cpp文件的项目有很大关系。我稍后会为其他编译器和平台添加MakeFiles。
为了充分发挥这一功能,任何想要使用TidBit的项目都应该包含一个指向主TidBits_Cpp存储库的子模块,然后拉出他们想要使用的子模块。他们可以立即运行所有单元测试而无需编写任何代码,然后开始编码。
来自父仓库的开销很小,因为它只包含一行包含以及一个包含一些单元测试内容和一个DoxyFile的文件夹。
这种系统的美妙之处在于,片段回购甚至不需要我自己。我可以在任何github存储库中调用子模块,其他
也可以考虑到静态断言,我确实拉了自己的断言,虽然这里有解决方案,但不必添加boost作为代码片段的依赖。我不这样做的主要原因是因为boost很大而且它不能作为git存储库使用,所以它不能作为子模块自动下载。
但是,正如Georg Fritzsche指出here,可以使用bpc从boost中提取部分。缺点是对于静态断言,例如,这仍然意味着70个文件...
如果您有兴趣,这是the link to my repository,但是现在考虑一下这个帖子不仅仅是一个例子。现在的代码仍处于开发阶段,尚不适合公开发布。也没有文件等。所有这些都是将来的。