4

LOC (コード行) の数に基づいてプログラムを理解するのにかかる時間について、広範で過度に一般化された、ほとんど役に立たないルールはありますか?

(どんなルールも広範で、過度に一般化され、ほとんど役に立たないことは理解しています。それで問題ありません。)

(問題の言語は Delphi ですが、広範で過度に一般化された、ほとんど役に立たないルールを探しているので、それは問題ではありません。)

4

8 に答える 8

5

プログラムを理解するのにかかる時間を決定するのは LOC の数ではなく、複雑さです。

私のプログラムに 100,000 行の print ステートメントがあるとしたら、プログラムは非常に明確に理解できると思います。しかし、for ループが 10 個の深さで入れ子になっているプログラムがあるとしたら、理解するのにはるかに時間がかかると思います。

循環的複雑度は、コードを理解するのがどれほど難しいかを大まかに示すことができ、コードに関する他の警告フラグを通知することもできます。

于 2009-07-06T12:27:16.367 に答える
4

ピア コード レビューに関する一部の論文では、1 時間あたり 100 ～ 400 行のコードが必要であると述べられています。

于 2009-07-06T12:39:47.007 に答える
3

特定の言語でプログラミングする個人ごとに異なるおおよその数があるため、これをグーグルで検索することはできません.

プログラム作成用にドレイクの 方程式を書こうとしています。

これが私の言いたいことです。

番組制作者について。

  • 人それぞれ、コードの書き方やコメントのスタイルが異なります。
  • すべてのプログラミング言語には異なるニュアンスと読みやすさがあります
  • アルゴリズムは、同じ言語でもさまざまな方法で実装できます
  • さまざまな人が使用するデータ構造は、非常に多様である傾向があります
  • ソース ファイルにコードを配布する方法の決定も、個人の好みによって異なります。

コードを読んでいる人に移動します。

  • 言語の問題に対する人の親しみやすさ
  • 使用されるアルゴリズムとデータ構造パターンに精通していることが重要
  • 人が一度に保持できる情報コンテキストの量が重要

環境に焦点を移すと、重要なことになります。

  • 気晴らしの量 (プログラマーとプログラムを読もうとする人の両方にとって)
  • プログラマーのコードリリース時間への近さ
  • 保留中の活動と読者側の動機
  • 人気のあるイベント (休暇、スポーツ イベント、映画の公開日!) の近く
于 2009-07-06T12:26:41.997 に答える
3

私はそれが O(n 2 ) であるという理論を持っています (他のすべての行と組み合わせて各行を理解する必要があるため)。

しかし、big-o 記法を使用して実際の数値を取得するときはいつものように、この答えは広範で、過度に一般化されており、ほとんど役に立ちません。

于 2009-07-06T12:31:40.470 に答える
3

コード レビュー メトリクス (同じものではありませんが、ほぼ同等です) では、経験豊富なコード レビュー担当者の場合、1 時間あたり約 50 ～ 100 LoC の範囲になります。

もちろん、これは彼らがレビュー、言語、複雑さ、親しみやすさなどで探しているものにも依存します..しかし、それはとにかく一般的な過度の一般化を与えるかもしれません.

于 2009-07-06T12:36:24.057 に答える
1

広く、過度に一般化され、ほとんど役に立たないルールを探しています。

あなたは、新しいコードベースを経営陣などに学習させるのにかかる時間を見積もる方法を見つけようとしているように思えます。その場合は、オンラインでコード スニペットを見つけて、それを理解するのにかかる時間を計ってください。それをスニペットの行数で割ります。パディングを追加します。バム！あなたのルールがあります。

于 2009-07-06T12:30:20.033 に答える
1

COCOMO方程式を見てください。それらには、コードのソース行に基づいた、広範で過度に一般化された、ほとんど役に立たないルールが含まれています。

于 2009-07-06T12:37:30.267 に答える
0

「プログラムはどれくらい複雑か」以外に、「どの程度理解しているか」などの変数があります。「プログラムの機能仕様など、他のことをどの程度理解していますか?」

新しいプログラムを使い始めるときは、できるだけ理解しないようにしています。具体的には、次のことを試みます。

  • 誰かが私に望んでいる変更の機能仕様を理解する (誰も私にプログラムを変更してほしくないなら、私はそれを理解する必要はまったくないでしょう)

  • 既存のプログラムの可能な限り最小のサブセットを見つけて理解します。これにより、他の以前の/既存の機能を壊すことなくその変更を行うことができます.

于 2009-07-06T12:37:24.463 に答える