我知道这个问题是一个相当广泛的问题，但我想知道决定为 R 创建（或不）一个新包的决定性点是什么。更具体地说，我要补充的是，这个问题不是关于使用 R 本身，更多关于编译各种脚本并将它们集成到新包中的决定。
在可能导致这些决定的要点中，我想到了（以一种非常不详尽的方式）：
在可能导致相反决定的几点中：
我可能已经忘记了许多可以在这两个列表中列出的点，而且，这些标准似乎部分是主观的。那么，您认为应该证明什么是合理的，并且在什么时候开始将各种功能和数据整合到一个新的文档化和广泛可用的包中？
我没有用 R 编程，但我用其他方式编程，我在这里看不到 R 特定的问题。
我想大多数人首先写一些东西是因为他们真的想要自己。相反，应该强烈抵制任何认为应该发布软件是因为它是要做的事情的感觉。聪明的人可能是糟糕的程序员，而且经常如此。
上市似乎是要确信你拥有的东西与已经公开的东西一样好或更好，并填补了空白。知道其他人想做同样的事情肯定是一种推动。
如果您有疑问，请不要发布。在许多社区中，由不加批判或缺乏经验的程序员发布的平庸或有缺陷的软件存在质量控制问题，尽管问题的严重程度仍有待商榷。乐观主义者认为可以忽略琐事，并且用户会足够快地暴露错误和限制；悲观主义者觉得我们被低质量的东西淹没了，很难区分赢家和输家。（另一方面，从发布中获得的经验是程序员改进的一部分。）
可能有一本关于这方面的书，但我想到了一些建议：
高质量的文档可以区分好的软件和好的代码，有时确实更明显。永远不要低估提供代码应得的文档所需的工作量。R 程序员似乎经常要求 R 用户尽可能多地了解正在实施的技术和最少的文档......
尽可能测试您的代码，以便您可以使用来自其他地方的真实数据重现已发布的解决方案。（如果您正在编写全新的东西，这可能会更困难，但并非不可能。此外，您可能经常会发现自己想知道这是他们的错误还是您的错误。）
程序员经常低估用户向程序抛出不合适数据的能力。因此，请考虑可能出现的问题，例如缺少值、如果程序假设为正则为零等等等。（这里的良性观点是，用户的工作是通过他们的反馈来发现问题并改进代码，但一个容易崩溃的程序不会提高你的声誉。）
这是一个重要而实际的问题。让我们首先区分编写包和在 CRAN 上发布包。
不写包的原因：
编写 R 包的原因：
提交包裹的原因（CRAN、Bioconductor、...）：
请记住，有选项#3；您可以要求相关软件包的维护者包含您的代码或数据。
我个人的包装触发因素是：
一位同事向我要代码。我编写的大部分代码至少与我自己的同事（他们使用 R 但自己不编写那么多程序）的要求一样多。
我使用包（文档）的正式要求来“强制”我清理和记录我的代码。
我同意@JohnRos 的观点，即编写包和发布包之间存在很大差异。
我通常会提前打包，但随后只将包裹设为“半公开”。也就是说，它可能在内部服务器（或 r-forge）上可用，因此我的同事可以访问该软件包。但是只有在该软件包被亲密的同事使用了几个月甚至几年之后，我才会发布到 CRAN。根据@Nick Cox 的第 3 点，这并没有带来所有的错误，而是相当多的错误。
软件包的版本（我将日期放在版本号中的破折号后面）使修复变得容易（“要做到这一点，请确保您至少安装了上周的版本”）
根据我的工作合同，我的雇主对是否以及如何向外界发布包有最终决定权。
我还没有一个好的打包策略是数据。
对您的原因列表的评论：
- 同一子字段中不存在其他包；
没有找到满足我需要的包会触发编写代码，但这与是否打包的决定无关。
- 需要与其他研究人员交流并允许实验的可重复性；
肯定的。可能已经需要在我使用的几台计算机之间共享。
在可能导致相反决定的几点中：
- 使用的部分方法已经存在于其他一些包中；
您可以将这些方法导入您的包/代码中：这是反对编写此类代码的一点，但与打包仅间接有关。
- 新功能的数量不足以证明创建新的独立包是合理的。
对我来说，启动一个包没有最小数量的函数。根据我的经验，包往往会“自动”增长。相反，在我发现自己几次从另一个包中分支出一个新包之后（因为最终证明某些辅助函数在主题上有所不同并且在其他情况下也很有用），我现在宁愿立即创建新包。
此外，如果您没有编写文档和测试，那么当创建包的“足够”数量的函数确实积累时，这可能是一项令人望而却步的工作。
（如果您确实立即编写它们，那么一旦您了解了工作流程，将其放入包中的额外工作就可以忽略不计）。