鉴于对可重复科学的压力，我想知道我最近的工作是否值得在出版物中包含示例代码。我使用的数据集非常大，因此发布这些必要性是没有意义的 - 但是，我在 R 中应用的统计方法通常不为我的听众所知（尽管我认为它们应该是）。
我在分析中使用经验正交函数分析 (EOF) 和广义加法模型 (GAM)。尤其是 GAM，广泛用于生态研究，但在物理科学中应用较少——我的工作跨越两个学科。
我肯定会参考我使用的 R 包，审阅者/读者自己查找这些参考资料（和包含的示例）并不难。所以，我的问题是，什么情况下最适合在出版物中包含可重现的代码？
代码是您实际所做的最准确的表示。因此，在我看来，您应该始终将代码与您的文章一起发布。
但是，编辑对此的抵制非常强烈。担心的是，如果审稿人可以访问代码，那么如果以后发现实质性的编码错误，期刊就会看起来很糟糕。鉴于莱维特论文等，这不是假设的恐惧。
Knuth 对文学编程有一些强烈的观点，你应该可以引用这些观点作为理由。如果您无法说服期刊接受您的代码作为出版物的组成部分，请考虑将其发布在您的个人网站上（例如Raj Chetty为他的许多论文所采用的方法）或将其作为 R 包发布。
最后，这是我写给我的编程学生的便条：
考虑发布您的代码。这样做将作为一种承诺手段，鼓励良好的习惯——使你自己的工作更轻松的习惯。发布您的代码还可以让其他人更轻松地扩展您的分析，这可能会导致更多人引用您的工作。发布您的代码也是一种很好的学术实践：它是您分析的最真实证明。将您的程序提供给全世界展示您即将获得的优美的编码技能。
科学的一个基本原则是可重复性。因此，答案是“包含”对基于数据分析的每篇论文/出版物进行分析所需的代码。
我说“包含”是因为您不需要将 R 代码直接放入论文中。许多（如果不是大多数）期刊都允许补充材料，这是一种选择。或者，将您的脚本提供给许多科学数据存档站点之一（例如 Figshare），然后（这就是杀手！）使用 Figshare 为您存放的脚本提供的 DOI 引用您自己的脚本。如果您也可以发布数据，那就更好了；Figshare 并不太关心大数据集。
以上适用于您使用其他包的代码，并且您的 R 脚本执行诸如加载和格式化数据、从其他包调用函数然后绘制或显示输出/结果等操作。如果您开发了新的 R 代码来实现特定方法，那么我会说将代码打包为 R 包并将其提交给 CRAN 或 r-forge 或类似的东西。
根据您的描述，前者（将分析脚本存放在回购中）将是最合适的。
我们最近在我们的研究所就可重复性研究进行了讨论。激励来自 Nature 社论 (http://arstechnica.com/science/2012/02/science-code-should-be-open-source-according-to-editorial/)，该社论认为你的所有代码都应该发布. 我完全同意这一点。即使您的数据集非常大，发布用于创建结果的 R 代码也可以让您一目了然。通常，论文的方法没有包含足够的细节来重现结果，在这种情况下，代码很有帮助。