h ファイル内の LOC の数が与えられた場合、最適なコード (デスクトップ アプリケーション) 内の C++ LOC の数はいくつになるでしょうか?
背景: 私は、C++ ソフトウェアを C# に移植するための労力見積もりと計画を行っています。
私の最初のアイデアは、LOC に基づいて大まかな見積もりを作成し、残りの LOC に移植された LOC を使用してプロセスを追跡することでした。移植速度が 200LOC/日であると仮定すると、1.5 人年になりました。この数字をお客様に提示したら、絶対に契約は取れません。
私が見つけたコードを詳しく見てみると、コードは非常に非効率的であり、多対多の C&P コードを使用し、独自のコンテナー クラスを実装しているなどです。したがって、C++ の LOC-Number は、同じものを実装するための努力を反映していないようです。機能。今、私の仮定は、ヘッダーファイルは機能をよりよく反映する必要があるということです。
いいえ。ヘッダー ファイルのサイズは、関連するコード ファイルのサイズの代用としては非常に不適切です。ヘッダーは API へのエントリ ポイントを表示するだけで、API が必要とするものをいくらでも隠すことができます。
つまり、単一の関数を宣言するヘッダーは、その実装ファイルに単一のパブリック関数があることを示しているだけです。実装ファイルには、関数が 1 つしかない場合もあれば、数百の関数が含まれる場合もあります。どちらが優れているというわけでもありません。どちらの開発アプローチにも問題はありません。これは、ヘッダーを使用して労力を見積もることができないことを意味します。
100,000 個の SLOC プログラムでは、開発よりもテストに多くの時間を費やすことになるため、SLOC を尺度として使用するのは無理があります。アプリケーションの機能に関するドキュメントにアクセスできる場合は、代わりにファンクション ポイントの使用を検討してください。私が聞いたところによると、それらは壊れにくいヒューリスティックの 1 つです。
開発に関しては、C# から C++ コードを呼び出すことができること、および C++/CX が C# を統合できることを忘れないでください。これにより、独立したコンポーネントを多かれ少なかれインクリメンタルに書き換えることができれば、移植の苦労がいくらか軽減されます。
同じ目的ではありませんが、好奇心のためclocに、中間 (プレアルファ) 段階のプロジェクトの LOC を確認したことがあります。それは十分に文書化されておらず、その場所のいくつかはわずかに汚いコードであるか、十分に計画されていませんでした.
C++ 100 2545 3252 11680
C/C++ Header 108 2847 12721 9077
C 4 1080 971 6298
CMake 33 241 161 1037
Bourne Shell 4 16 0 709
Python 8 90 72 423
CSS 1 63 21 422
PHP 5 23 21 295
Javascript 5 42 23 265
JSON 4 0 0 183
XML 1 11 171 72
make 1 13 0 15
Bourne Again Shell 2 10 0 14
ご覧のとおり、ヘッダー LOC とソース LOC の比率は です0.777。ただしaverage、何に対しても良い指標ではありません。ただし、コメント行などの他のメトリックとともに、さまざまなパラメーターや開発段階を示すために、あいまいな線が描かれる場合があります。優れたヒューリスティックスを考え出すには、よく知られているコード ベースをさらに調査する必要があります。
しかし、最終的には、どのような手段を講じても、間違っている可能性のある仮定を結論付けることができます。
ヘッダー ファイルはインジケーターではない可能性があります。
ヘッダー ファイルには、通常、関数宣言 (関数の呼び出し方法に関するインターフェイスまたは命令) が含まれています。
ソース ファイル内の関数は、ゼロ ステートメントまたは数百の LOC である可能性があります。関数宣言を見ても、関数内のステートメントまたは行の数を知ることはできません。
多くの LOC カウンターには、ヘッダー ファイルとソース ファイルの両方が含まれています。