私のキャリアを通して、関数の長さについて多くの議論を聞いてきました。 より深い質問-コードを別の関数に移動する必要があるのはいつですか？ 推奨事項はサイズに基づいている場合があります。たとえば、関数は画面に収まる必要があります。 その他は再利用に基づいています-複数回使用されるコードはすべて別の関数に配置する必要があります。 ただし、コードが1回だけ使用される場合は、そのままにしておくことができます。 意図と実現の分離についての議論には多くの意味があるように思えます。 コードが何をしているのかを理解するためにコードの検索に時間を費やす必要がある場合は、それを関数に入れて、「what」という質問に答える名前を付ける必要があります。 その後、次回関数の意味がすぐに明らかになり、ほとんどの場合、関数がどのように機能するかは気にしません。 言い換えれば、関数の本体で何が起こるか。
この原則を適用し始めたとき、私は非常に小さな関数を書く習慣を身に付けました-通常は数行以下です。 6行より長い関数は、すでに匂いがします。 1行のコードで関数を使用することは非常に一般的です。 ケント・ベックはかつて私に元のSmalltalkシステムの例を見せてくれました。サイズが重要でないことを本当に理解するのに役立ちました。 その年のSmalltalkは白黒のマシンで働いていました。 テキストまたはグラフィックを強調表示する必要がある場合は、ビデオを反転する必要がありました。 スケジュールを担当するSmalltalkのクラスには「ハイライト」メソッドが含まれており、その実装には「reverse」メソッドの呼び出しという1行しかありませんでした。 メソッドの名前は実装よりも長かったが、このコードの意図と実装の間には大きな距離があるため、問題ではなかった。
一部の人々は、パフォーマンスへの呼び出しの影響に関心があるため、短い関数を心配しています。 私が若かったとき、それは時々重要でしたが、今日はまれです。 最適化コンパイラは、キャッシュしやすいため、多くの場合、より短い関数でより適切に動作します。 いつものように、パフォーマンスの最適化では、まず第一に、一般的な推奨事項が意味をなします。 正しい解決策は、コードを関数から元の場所に戻すことです。 しかし、多くの場合、小さな関数の存在により、最適化する他の方法を見つけることができます。 リストに対してisEmptyメソッドを使用することに人々が反対したときのことを覚えています。 標準的な方法はaList.length == 0でした。しかし、これは関数の名前が意図を示している場合にすぎません。これは、長さをチェックするよりもコレクションの空を判断するより速い方法がある場合のパフォーマンスに役立ちます。
このような小さな関数は、名前が十分な場合にのみ機能するため、これに注意する必要があります。 時間が経つにつれてスキルが向上し、このアプローチにより自己文書化コードが大幅に増加する可能性があります。 より高いレベルの機能はストーリーのように読むことができ、読者は詳細を知る必要がある場合に掘り下げる機能を選択します。