小さな機能を書くときにスパゲッティコードを避ける

Question

"スパゲッティコード"を理解することは、論理的でわかりやすい目的でコードの1つのブロックから別のブロックにジャンプするコードベースです。最も一般的な犯罪者は、GOTOの声明のようです。

私は現在、Clean Code：Handbook of Agile Software Craftsmanshipの機能の章を読み、参照しています。著者は、自明のことながら、機能の大きさに関して非常に厳しいです。私は機能を小さく保つという考えを理解していますが、彼は約5行でなければならないことを示唆しています。クラスは確かに読みやすくなりますが、私は小さな機能を記述してスパゲティコードを作成することを恐れています。関数が小さくなると、誤ってより高い抽象を作成するようにも見えます。

コードはどの時点でスパゲッティコードになりますか？どのように抽象的であるか要旨？どんな答えでも大いに役立ちます。

私は初めての質問ですが、スタックオーバーフローの長いフォロワーですので、私の投稿に関する提案も歓迎します。

ありがとうございます！

Answer 1

すでにコメントの中で述べたように、絶対的なルールはありません。最後に、コードの読みやすさを目指すべきです。しかし、それはあなたの方法の長さに関するすべてではありません。ロバートマーティンは、抽象度に応じてメソッドを順序付けることを提案しています。抽象メソッドはクラスの最上位にある必要があります。メソッドが多いほど、そのメソッドを配置する必要があります。

もう1つのimportandはメソッド名です。メソッドが何をするのかを明確にするためには、それをよく選択する必要があります。メソッド名を賢明に選択すると、コメントはほとんど必要ありません。例えば、if文を考えてみます。文の意図がより明確になるため

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

がはるかに読みやすい

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

を超えています。原因の2番目の例では、コメントを追加することができます。しかし、コメントはしばしば時代遅れになる（それについてのロバート・マーティンの本には別の章がある）。私は、このスタイルのプログラミングは多くの短い方法につながると思います。

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

希望します。

Answer 2

ここにコメントと回答に同意します。実践的な観点からは、ロバート・マーティンが彼の著書に書いている考えは、毎回非常に良い方向付けであり、私はこの「ルール」に可能な限り近づくよう努力しています。実際には5つの方法があります。

私の目でスパゲッティコードを避ける最良の方法は、（Cohesionの高い）クラスを書くことです。欠点は、あなたがクラス全体になって、新入社員がプロジェクトに入るのが少し難しくなることです。

Answer 3

私は機能を小さくするという考えを理解していますが、約5行にする必要があります。理想的な音

:)

クラスは確かに読みやすくなっている間、私は小さな関数を書くことでスパゲッティコードを作成するのが怖いです。

スパゲッティコードは、（同じ機能、つまり、下位レベルのIOコードと上位レベルのアプリケーションロジックで異なる抽象レベルを持つ）コードが場所によってジャンプすることによって発生します。小さな機能を抽出すると、あなたの結果はスパゲッティコードから遠ざかります。

どの時点でスパゲッティコードになりますか？

コードでは、プログラマが精神的なジャンプ（スイッチコンテキスト）を行ごとに強制すると、コードはスパゲッティコードになります。 GOTOを使っているかどうかにかかわらず、これは当てはまります（GOTOは問題をさらに悪化させる可能性があります）。