Stata 如何组织子例程供多个命令使用？

我正在用两个新命令创建一个包，比如

foo

和

bar

例如，如果

foo.ado

包含：

program define foo
    ...
    rex
end

program define rex
    ...
end

但是我的另一个命令，

bar.ado

，也需要调用

rex

。我应该把rex放在哪里

我看到以下几个选项：

同时创建一个

rex.ado

文件

创建一个

rex.do

文件，并使用

在每个文件底部包含“`c（sysdir_plus）'r/rex.do”

将其包含在

foo.ado

和

bar.ado

中

将代码复制到

foo.ado

和

bar.ado

中，这看起来很难看，因为现在代码必须在两个地方维护

组织

foo

和

bar

所需的子程序的最佳实践是什么

此外，子例程是否应该被调用

rex

，

\u rex

，或者其他什么-可能是

\u foobar\u rex

-来指示它实际上是

foo

和

bar

所依赖的子命令，而不是独立运行的单独命令？

也创建一个rex.ado文件 你的问题有点太宽泛了。就我个人而言，我会选择第一个安全的选项，尽管这实际上取决于项目的结构。有时在单个

ado

文件中包含

rex

就足够了。例如，如果

foo

是一个包装器命令，就会出现这种情况。然而，对于大多数其他用例，包括共享一个公共程序的两个命令，我坚信您将需要一个单独的

ado

文件

第二个选项显然是不必要的，因为第一个选项做同样的事情，而且它不必每次调用时都加载程序。在编程环境中，第三个选项可能是最糟糕的，因为它可能会产生冲突，并且很难在将来维护

---

关于命名约定，我建议仅当您将程序作为子例程包含在

ado

文件中时，才使用类似

\u rex

的东西。否则，

rex

会做得很好，也会表明该程序在您的项目中有更广泛的范围。在我看来，最好在

ado

文件的开头使用注释对

rex

的预期用途进行更详细的解释，而不是试图将其包含在名称中。

答案还取决于（1）谁在使用您的代码？例如，如果您设想将来修改代码，他们是否会对更新的需求感到满意？（2） 谁在读你的代码？他们可能会被你的个人命名习惯所困扰吗？（3）

rex

本身需要的可能性有多大？这些都是有效的观点，但当问题如此笼统时，很难给出可靠的建议。@ChrisP你觉得我的答案有用吗？@PearlySpencer，谢谢你的回答。认可的。如果没有包级名称空间，冲突似乎是一个很大的风险；我必须仔细选择名称，因为两个用户编写的命令可能有一个

rex.ado

文件。据我所知，没有办法让

user\u cmd1.rex

和

user\u cmd2.rex

。