我在两个条件下剪切我的函数：当它提高主函数的代码的可读性时，p>

I cut up my functions under two conditions :

1. ，和/或


2. 例如，如果相同的代码在同一个函数中使用了几次。

我包括所谓的辅助函数在主函数的文件中，但只要这些辅助函数不在任何其他函数中使用。实际上，我认为它们嵌套在main函数中。我理解你的版本控制的参数，但更改辅助函数是为了改变主要功能的性能，所以我认为没有问题，保持在同一个文件。

I do include the so-called helper functions in the file of the main function, but only as long as those helper functions are not used in any other function. Actually, I consider them nested within the main function. I do understand your argument for version control, but changing the helper function comes down to changing the performance of the main function, so I see no problem in keeping them in the same file.

一些帮助函数可能用于不同的其他函数，然后我将它们保存在自己的文件中。通常我会导出这些功能，因为他们可能是用户感兴趣。与 lm 和底层 lm.fit 比较，高级用户可以使用 lm.fit 可以加速代码等。

Some helper functions might be used in different other functions, and then I save them in their own file. Often I do export those functions, as they might be of interest for the user. Compare this to eg lm and the underlying lm.fit, where advanced users could make decent use of lm.fit for speeding up code etc.

我使用的命名约定在很多软件包通过一个点前面的每个隐藏功能。这样，

I use the naming convention used in quite some packages (and derived from linux), by preceding every "hidden" function by a dot. So that makes

.helper.function <- function(x, ...){
    ... some code ...
}

main.function <- function(x, ...){
    ...some code, including .helper.function(y, ...)
}

我显式@export所有需要导出的函数，从不帮助函数。判断一个函数是否可能对最终用户感兴趣并不总是容易，但在大多数情况下它很清楚。

I explicitly @export all functions that need exporting, never the helper functions. It's not always easy to judge whether a function might be of interest to an end user, but in most cases it's pretty clear.

举一个例子：几行代码切断NA行我认为一个帮助函数。一个更复杂的函数，用于将数据集转换为正确的格式，并导出和归档。

To give an example : A few lines of code to cut off NA lines I consider a helper function. A more complex function to convert the dataset to the correct format I export and document.

YMMV