8

「スパゲッティ コード」についての私の理解は、論理的かつ読みやすい目的なしに、あるコード ブロックから別のブロックにジャンプするコード ベースです。最も一般的な違反者は GOTO ステートメントのようです。

私は現在、Clean Code: A Handbook of Agile Software Craftsmanship の機能の章を読んだり参照したりしています。著者は、自明のことですが、関数のサイズに関して非常に厳格です。関数を小さく保つという考えは理解していますが、彼は関数を 5 行程度にすることを提案しています。クラスは確かに読みやすくなりますが、より小さな関数を記述してスパゲッティ コードを作成することを恐れています。より小さな関数は、より高度な抽象化も意図せずに作成するようです。

コードがスパゲッティ コードになるのはどの時点ですか? どれくらい抽象的で抽象的すぎますか? どんな答えでも非常に役に立ちます。

余談ですが、私は Stack Overflow の長年のファンですが、質問を投稿するのはこれが初めてなので、私の投稿に関する提案も大歓迎です。

どうもありがとう！

4

3 に答える 3

6

コメントですでに述べたように、絶対的なルールはありません。最後に、コードを読みやすくすることを目標にする必要があります。しかし、メソッドの長さはそれだけではありません。Robert Martin は、抽象度に従ってメソッドを並べることを提案しています。抽象メソッドはクラスの最上位に配置する必要があり、メソッドが多ければ多いほど、より深い位置に配置する必要があります。

もう 1 つの重要な側面は、メソッド名です。メソッドの機能を明確にするために、適切に選択する必要があります。メソッド名を賢く選択すれば、コメントはほとんど必要ありません。たとえば、if ステートメントを考えてみます。

if(isValidAge(value)) {
   ...
}

よりもはるかに読みやすい

if(value > 10 && value < 99) {
   ...
}

発言の意図が明確になるからです。もちろん、2 番目の例ではコメントを追加できます。しかし、コメントは時代遅れになることがよくあります (Robert Martin の本には、それに関する追加の章があります)。このスタイルのプログラミングは、多くの短いメソッドにつながると思います。

適切な抽象化レベルを選択するのは困難です。私の経験によると、低レベルの抽象化から始める方が簡単です。そのため、まず問題をうまく解決することに集中できます。後でさらに抽象化が必要になった場合でも、コードをリファクタリングできます。TDDは大いに役立ちます！

お役に立てれば ...

于 2013-08-21T21:20:35.310 に答える
1

関数を小さく保つという考えは理解していますが、彼は関数を 5 行程度にすることを提案しています。

それは理想的に聞こえます:)

クラスは確かに読みやすくなりますが、より小さな関数を記述してスパゲッティ コードを作成することを恐れています。

スパゲッティ コードは、場所から場所へのコード ジャンプによって発生します (同じ関数内に異なるレベルの抽象化 (低レベルの IO コードと高レベルのアプリケーション ロジック) がある場合)。小さな関数を抽出すると、結果はスパゲッティ コードから遠ざかり、近づくことはありません)。

コードがスパゲッティ コードになるのはどの時点ですか?

コードがあなた (プログラマー) に精神的なジャンプ (コンテキストの切り替え) を行から行へと強制する場合、そのコードはスパゲッティ コードです。これは、GOTO を使用するかどうかに関係なく当てはまります (ただし、GOTO は問題をさらに悪化させる可能性があります)。

于 2013-08-22T15:08:22.770 に答える