32

バックグラウンド

私はRパッケージを作成しましたが、現在、共同編集者（Rを初めて使用する最近のCS卒業生）がコードの編集とリファクタリングを行っています。その過程で、彼は私の関数をより小さく、より一般的な関数に分割しています。

彼がやっていることは理にかなっていますが、私が始めたときpackage.skeleton()、私は関数ごとに1つのファイルを持っていました。現在、彼は主要な関数が依存する関数を追加しましたが、それは関数自体の外での使用が制限されている可能性があります。

彼は、すべての関数を1つのファイルにまとめることを提案していますが、異なるファイルで作業する場合はバージョン管理を行う方が簡単なので、私は反対です。

それ以来、テキスト内の各機能を文書化するためにroxygenを使い始めました。

質問

関数を処理するための推奨される方法は何ですか：明らかにヘルパー関数はメイン関数のままである必要がありますが、ヘルパー関数をどの程度文書化する必要がありますか？

コメントの@export提案は役に立ちますが、他の人がどのようにコードを整理しているか知りたいです。

4

1 に答える 1

32

私は2つの条件の下で私の機能を切りました：

  1. main関数のコードの可読性が向上する場合、および/または
  2. コードのコピー貼り付けを回避する場合。たとえば、同じ関数内で同じコードが2、3回使用される場合。

いわゆるヘルパー関数をメイン関数のファイルに含めますが、それらのヘルパー関数が他の関数で使用されていない場合に限ります。実際、私はそれらをmain関数内にネストされていると考えています。バージョン管理についてのあなたの議論は理解していますが、ヘルパー関数を変更すると、メイン関数のパフォーマンスが変更されることになります。したがって、それらを同じファイルに保持しても問題はありません。

一部のヘルパー関数は他のさまざまな関数で使用される可能性があり、それらを独自のファイルに保存します。これらの関数はユーザーの興味を引く可能性があるため、エクスポートすることがよくあります。これを、たとえば、上級ユーザーがコードの高速化などに適切に利用できるlm基礎となるものと比較してください。lm.fitlm.fit

私は、すべての「隠し」関数の前にドットを付けることで、かなりのパッケージで使用されている（そしてLinuxから派生した）命名規則を使用しています。だからそれは

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

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

ヘルパー関数ではなく、エクスポートが必要なすべての関数を明示的に@exportします。関数がエンドユーザーにとって興味があるかどうかを判断するのは必ずしも簡単ではありませんが、ほとんどの場合、それはかなり明確です。

例を挙げると、NA行を切り捨てるための数行のコードがヘルパー関数だと思います。データセットをエクスポートして文書化する正しい形式に変換するためのより複雑な関数。

YMMV

于 2011-03-31T00:28:54.253 に答える