ルーチン、プロシージャ、メソッド - 呼び名が何であれ、これらは開発者にとって重要なビルディング ブロックです。最も重要な特徴として、どのような特徴を評価しますか?
(回答ごとに 1 つの特性を提供することで、個別に投票することができます。つまり、この質問の目的は、1 つの特性を選択することではなく、重要な特性をすべて強調することです。)
ルーチン、プロシージャ、メソッド - 呼び名が何であれ、これらは開発者にとって重要なビルディング ブロックです。最も重要な特徴として、どのような特徴を評価しますか?
(回答ごとに 1 つの特性を提供することで、個別に投票することができます。つまり、この質問の目的は、1 つの特性を選択することではなく、重要な特性をすべて強調することです。)
最も重要な基準は、目的が 1 つであることだと思います。
その後、その目的 (およびその目的のみ) を正しく満たすこと。
自己コメント プロシージャ名。
例: GetStoreFromAddress GetCarsByMake
良いルーチンと悪いルーチンを区別する単一の基準はありません。
基準には次のものがあります。
簡単に単体テストできるはずです。
ルーチンの名前は、その機能に 1 対 1 で対応しています。
関数 X が X と Y を実行する頻度、または X のすべてではなく X の大部分を実行する頻度は驚くべきものです。
人間が簡単に読んで理解できるように設計されています - それがなければ、ここにリストされている他のすべての素晴らしい属性を持つように変更するのははるかに困難です
やろうとすることの数。
これが正確に 1 でない場合は、おそらく問題があります。
予期しない副作用があってはなりません。
優れたエラー処理 (信頼性)
簡潔
(これは半分楽しい答えになるはずでしたが、単語をそのまま投稿することはできませんでした!)
ルーチンを API の一部と考えれば、これはより簡単に答えられると思います。少なくとも真に有用なシステムではなく、スタンドアロンのルーチンは多くありません。正直なところ、ルーチンを作成する際に考慮すべき最も重要なことは次のとおりです。
直観性 私の一連の指示はどれほど直観的ですか? 多くのドキュメントに目を通さなくても、人々は目的を理解できるでしょうか?
直交性 私のルーチンはどの程度直交しているか? それぞれが 1 つの特定のタスクを実行しますか、それとも同じことを実行する複数の (ただしわずかに異なる) 方法がありますか? 存在する場合、これは悪いことであり、おそらく API を再設計する必要があります。
コンパクトさ 単純なタスクを実行するのにどれくらいの API が必要ですか? 何かを成し遂げるために多くのことを学ぶ必要がありますか?それとも、直感的で強力な何かを行うルーチンをいくつか実行するだけで十分でしょうか? 特定のドメインで適切なバランスを取るには、このトレードオフと直交性を比較検討する必要があります。
ルーチン名から、そのルーチンが何をするかを知ることができます (そして、コードをチェックすると、自分が正しかったことがわかります ;-)
原子的でなければならない
コード行。
ルーチンが使用された後に必要な編集の数を追跡する必要があります。「良い」ルーチンとは、編集がほとんど必要ないルーチンです。「悪い」ルーチンは、多くの修正が必要な場合に、間違いなくそうであることが証明されます。
これは、各編集後に更新される各メソッド呼び出しのコメント ヘッダーで簡単に実現できます。
1 つのことを行うか、複数のことを他の関数に委任します
明快さ - 理解しやすい
このルーチンは、全体を通して一貫したレベルの抽象化を使用します。
私は十分に文書化された(そして実際に施行された)事前および事後条件を言うでしょう.
単一のリターン ポイント