機能が短すぎますか？

同じロジックを複数回記述していることに気付くたびに、通常、それを関数に固定するため、アプリケーション内でそのロジックを維持する必要がある場所は1つだけです。副作用は、次のような1行または2行の関数になることです。

function conditionMet(){
   return x == condition;
}

または

function runCallback(callback){
   if($.isFunction(callback))
     callback();
}

これは怠け者ですか、それとも悪い習慣ですか？これは、非常に小さなロジックの関数呼び出しの数が多くなるためです。

Hehe、Brown氏、私が会うすべての開発者を説得して、機能をこれほど小さく保つことができれば、ソフトウェアの世界はより良い場所になると信じています！

1）コードが読みやすくなります。

2）読みやすさのために、コードのプロセスを把握するのは簡単です。

3）DRY-自分自身を繰り返さないでください-これに非常に順応しています！

4）テスト可能。小さな関数は、あまりにも頻繁に見られる200行のメソッドよりもテストが100万倍簡単です。

ああ、パフォーマンスの点で「関数ホッピング」を心配しないでください。「リリース」ビルドとコンパイラーの最適化がこれを非常にうまく処理してくれます。パフォーマンスは、システム設計の他の場所の99％の時間です。

これは怠け者ですか？-非常に反対です！

これは悪い習慣ですか？- 絶対違う。あまりにも一般的であるtarボールや「God Objects」よりも、この方法でメソッドを作成した方が良いです。

私の仲間の職人の良い仕事を続けてください;）

次のいずれかの場合、リファクタリングされたメソッドは短すぎると思います。

• メソッドにする以外の目的で、プリミティブ操作を複製します。

例：

boolean isNotValue() {
   return !isValue();
}

または...

• コードは一度だけ使用され、その意図は一目で理解しやすいです。

例：

void showDialog() {
    Dialog singleUseDialog = new ModalDialog();
    configureDialog(singleUseDialog);
    singleUseDialog.show();
}

void configureDialog(Dialog singleUseDialog) {
    singleUseDialog.setDimensions(400, 300);
}

これは有効なパターンである可能性がありますが、この例では、オーバーライドまたは別の場所でこのコードを再利用する場合を除き、configureDialog（）メソッドをインライン化します。

機能が短すぎますか？一般的にいいえ。

実際、それを保証する唯一の方法は：

1. デザインにすべてのクラスが見つかりました
2. あなたの機能はただ一つのことをしています。

関数をできるだけ小さくすることです。または、言い換えれば、それ以上抽出できないまで関数から関数を抽出します。これを「ドロップするまで抽出」と呼びます。

これを説明するには：関数は、変数によって通信する機能のチャンクを持つスコープです。クラスは、変数によって通信する機能のチャンクを持つスコープでもあります。したがって、長い関数は、小さなメソッドを使用して常に1つ以上のクラスに置き換えることができます。

また、別の関数を抽出するのに十分な大きさの関数は、定義により複数のことを行っています。したがって、ある関数を別の関数から抽出できる場合は、その関数を抽出する必要があります。

一部の人々は、これが機能の急増につながることを心配しています。彼らは正しい。そうなる。それは実際には良いことです。関数には名前があるので、それは良いことです。適切な名前を選択することに注意している場合、これらの関数は、コードを介して他の人を誘導する標識投稿として機能します。実際、適切な名前の名前空間内の適切な名前のクラス内の適切な名前の関数は、読者が迷子にならないようにするための最良の方法の1つです。

cleancoders.comのClean CodeのエピソードIIIには、これに関する詳細があります。

うわー、これらの答えのほとんどはまったく役に立ちません。

そのアイデンティティが定義である関数を書かないでください。つまり、関数名が単に英語で記述された関数のコードブロックである場合は、関数として記述しないでください。

あなたの関数conditionMetとこの他の関数を考えてくださいaddOne（私のさびたJavaScriptを許してください）：

function conditionMet() { return x == condition; }

function addOne(x) { return x + 1; }

conditionMet適切な概念的定義です。addOneはトートロジーです。「条件が満たされた」と言うだけではconditionMet何conditionMetが必要なのかわからないので良いのですがaddOne、英語で読むとなぜ愚かなのかがわかります。

"For the condition to be met is for x to equal condition" <-- explanatory! meaningful! useful!

"To add one to x is to take x and add one." <-- wtf!

まだ聖なるものへの愛のために、トートロジー関数を書かないでください！

（そして同じ理由で、コードのすべての行にコメントを書かないでください！）

コメントを追加することでコードの意図を改善できると思う場合は、そのコメントを追加するのではなく、独自のメソッドにコードを抽出します。コードがどれほど小さくても。

たとえば、コードが次のようになっている場合：

if x == 1 { ... } // is pixel on?

代わりに次のようにします。

if pixelOn() { ... }

と

function pixelOn() { return x == 1; }

または、言い換えると、メソッドの長さではなく、自己文書化コードについてです。

これがまさにあなたがやりたいことだと思います。現在、その機能は1行または2行だけかもしれませんが、時間が経つにつれて大きくなる可能性があります。また、より多くの関数呼び出しがあると、関数呼び出しを読んで、そこで何が起こっているのかを理解できます。これにより、コードが非常に乾燥した（自分自身を繰り返さない）ことができます。

私が見た他のすべての投稿に同意します。これは良いスタイルです。

このような小さなメソッドのオーバーヘッドは、オプティマイザーが呼び出しを最適化し、コードをインライン化するため、ゼロになる場合があります。このような単純なコードは、オプティマイザーが最善の仕事をすることを可能にします。

コードは明快さと単純さのために書かれるべきです。メソッドを2つの役割のいずれかに限定しようとしています。または作業を実行します。これにより、1行のメソッドが生成される場合があります。これを上手にやればやるほど、コードはより良くなります。

このようなコードは、凝集度が高く、結合度が低い傾向があるため、適切なコーディング方法です。

編集：メソッド名に関する注意。メソッドが実行する方法ではなく、実行する方法を示すメソッド名を使用します。verb_noun（_modifier）が適切な命名スキームであることがわかりました。これにより、Select_Customer_Using_NameIdxではなくFind_Customer_ByNameなどの名前が付けられます。2番目のケースは、メソッドが変更されたときに不正確になる傾向があります。最初のケースでは、顧客データベースの実装全体を交換できます。

1行のコードを関数にリファクタリングするのは過度に思えます。ver loooooong / comples行やエクスペションなどの例外的なケースがあるかもしれませんが、機能が将来成長することがわかっている場合を除き、これを行いません。

最初の例では、グローバルの使用に関するヒント（コード内の他の問題について言及する場合もしない場合もあります）をさらにリファクタリングし、これら2つの変数をパラメーターとして作成します。

function conditionMet(x, condition){
   return x == condition;
}
....
conditionMet(1,(3-2));
conditionMet("abc","abc");

このconditionMet例は、次のように条件が長く繰り返される場合に役立ちます。

function conditionMet(x, someObject){
   return x == ((someObject.valA + someObject.valB - 15.4) / /*...whole bunch of other stuff...*/);
}

このことを考慮：

簡単な衝突検出機能：

bool collide(OBJ a, OBJ b)
{
    return(pow(a.x - b.x, 2) + pow(a.y - b.y, 2) <= pow(a.radius + b.radius, 2));
}

コード内に常に「単純な」1つのライナーを記述した場合、最終的に間違いを犯す可能性があります。さらに、それを何度も書くのは本当に拷問になります。

いいえ、それはめったに問題ではありません。今、誰かが関数がコードの1行よりも長くはならないと感じた場合（それがそんなに単純なことができる場合のみ）、それは問題であり、彼らは適切なものを考えていないため、ある意味で怠け者になります。

短すぎると思いますが、これは私の主観的な意見です。

なぜなら：

• 1回または2回しか使用されない関数を作成する理由はありません。defs suckへのジャンプ。特に驚くほど高速なVSおよびC ++コードの場合。
• クラスの概要。あなたが何千もの小さな機能を持っているとき、それは私を怒らせます。クラス定義を表示して、SetXToOne、SetYToVector3、MultiplyNumbers、+ 100個のセッター/ゲッターがどのように機能するかではなく、クラスの機能をすぐに確認できるのが楽しみです。
• ほとんどのプロジェクトでは、これらのヘルパーは1つまたは2つのリファクタリングフェーズの後に重荷になります。その後、「すべて検索」->削除を実行して、廃止コード（通常は約25％以上）を削除します。

長い関数は悪いですが、3行より短く、1つだけを実行する関数も同様に悪いです。

だから私はそれが次の場合にのみ小さな関数を書くと言うでしょう：

• 3行以上のコード
• ジュニア開発者が見逃す可能性のあるもの（わからない）
• 追加の検証を行います
• 使用される、または少なくとも3倍使用される
• 頻繁に使用されるインターフェースを簡素化
• 次のリファクタリング中に重荷になりません
• テンプレートの特殊化など、特別な意味があります
• いくつかの分離ジョブを行います-const参照、可変パラメーターに影響し、プライベートメンバーの取得を行います

次の開発者（シニア）は、SetXToOneのすべての関数を覚えるよりも、やるべきことがあると思います。いずれにしても、彼らはすぐに死に変わるでしょう。

私は例が好きではありません。1、i番目の一般名のため。

conditionMetジェネリックではないようですので、特定の条件を表しますか？好む

isAdult () = { 
  age >= 18 
}

これでいいでしょう。意味の違いですが、

isAtLeast18 () { age >= 18; } 

私には大丈夫ではないでしょう。

たぶんそれは頻繁に使用され、後で変更される可能性があります：

getPreferredIcecream () { return List ("banana", "choclate", "vanilla", "walnut") }

大丈夫です 複数回使用すると、必要に応じて1つの場所を変更するだけで済みます。明日はホイップクリームが可能になるかもしれません。

isXYZ (Foo foo) { foo.x > 15 && foo.y < foo.x * 2 }

アトミックではないので、良いテストの機会を与えるはずです。

関数を渡す必要がある場合は、もちろん、好きなものを渡し、それ以外の場合は愚かな外観の関数を作成します。

しかし、一般的に、短すぎる関数よりも長すぎる関数が多く見られます。

最後の言葉：一部の関数は冗長に書かれているため、適切に見えるだけです。

function lessThan (a, b) {
  if (a < b) return true else return false; 
}

あなたが見るなら、それは同じであると

return (a < b); 

あなたには問題はありません

localLessThan = (a < b); 

の代わりに

localLessThan = lessThan (a, b); 

コードなしのようなコードはありません！

シンプルに保ち、複雑になりすぎないようにしてください。

それは怠beingではなく、あなたの仕事をしています！

はい、短いコード機能を使用しても大丈夫です。「ゲッター」、「セッター」、「アクセサー」などのメソッドの場合、以前の回答で述べたように、非常に一般的です。

時々、これらの短い「アクセサ」関数は仮想的です。サブクラスでオーバーライドされると、関数はより多くのコードを持つためです。

多くの関数で、グローバルでもメソッドでも、それほど短くなく機能したい場合は、通常、直接リターンの代わりに「結果」変数（パスカルスタイル）を使用します。これは、デバッガを使用するときに非常に役立ちます。

function int CalculateSomething() {
  int Result = -1;

   // more code, maybe, maybe not

  return Result;
}

短すぎることは決して問題ではありません。短い機能のいくつかの理由は次のとおりです。

再利用性

たとえば、setメソッドなどの関数がある場合、パラメーターが有効であることを確認するために関数をアサートできます。このチェックは、変数が設定されているすべての場所で実行する必要があります。

保守性

将来変更される可能性があると思われるステートメントを使用する場合があります。たとえば、列にシンボルを表示するようになりましたが、後でそれが別のもの（またはビープ音）に変わる可能性があります。

均一

たとえば、ファサードパターンを使用しており、関数が行う唯一のことは、引数を変更せずに関数を別の関数に正確に渡すことです。

コードセクションに名前を付けるとき、それは本質的にそれに名前を付けるためです。これにはいくつかの理由がありますが、重要な点は、プログラムに追加する意味のある名前を付けることができるかどうかです。「addOneToCounter」のような名前は何も追加しませんが、追加しconditionMet()ます。

スニペットが短すぎるか長すぎるかを見つけるためのルールが必要な場合は、スニペットの意味のある名前を見つけるのにかかる時間を検討してください。妥当な時間内にできない場合、スニペットは適切なサイズではありません。

いいえ、しかしそれはあまりにも簡潔になる可能性があります。

要確認：コードは1回書かれますが、何度も読みます。

コンパイラ用のコードを書かないでください。コードを保守する必要がある将来の開発者向けに作成してください。

はい、機能はますます小さくなり、良いか悪いかは使用している言語/フレームワークに依存します。

私の意見では、主にフロントエンドテクノロジで作業しています。小さな関数は主にヘルパー関数として使用されます。アプリケーションに共通のロジックが多すぎる場合、たくさんの小さな関数が作成されます。

ただし、共通のロジックを持たないアプリケーションでは、小さな関数を作成する必要はありませんが、コードをセグメントに分割して、管理および理解しやすくすることができます。

一般に、巨大なコードを小さな関数に分割することは非常に良いアプローチです。最新のフレームワークと言語では、そうする必要があります。

data => initScroll(data)

ES 2017 JavaScriptおよびTypescriptの匿名関数です

getMarketSegments() {
 this.marketService.getAllSegments(this.project.id)
  .subscribe(data => this.segments = data, error => console.log(error.toString()));
}

上記のコードでは、3つの関数宣言と2つの関数呼び出しを見ることができます。これは、Angular 4のTypescriptを使用した単純なサービス呼び出しです。あなたの要件としてそれを考えることができます

([] 0)
([x] 1)
([x y] 2)

上記はclojure言語の3つの匿名関数です

(def hello (fn [] "Hello world"))

上記はclojureの機能宣言です

はい

incrementNumber(numb) { return ++numb; }

そうするのは良い習慣ではありませんが、Angular FrameworkのようにHTMLタグでこの関数を使用している場合、Angular HTMLテンプレートでIncrementまたはDecrementがサポートされていない場合は、これが解決策になります私。

別の例を見てみましょう

insertInArray(array, newKey) {
 if (!array.includes(newKey)) {
   array.push(newKey);
 }
}

上記の例は、Angular HTMLテンプレート内の配列を再生する際に必須です。そのため、小さな関数を作成する必要がある場合があります

私は、現時点で与えられたほとんどの答えに同意しません。

最近、次のようなすべてのクラスメンバーを作成する同僚を見つけました。

 void setProperty(int value){ mValue=value; }
 int getProperty() const { return (mValue); }

これは散発的な場合には良いコードかもしれませんが、多くのプロパティを持つ多くのクラスを定義する場合は間違いありません。これで、上記のようなメソッドは書かれないとは言いたくありません。しかし、ほとんどのコードを実際のロジックの「ラッパー」として書くことになった場合、何か問題があります。

おそらくプログラマーは全体的なロジックを見逃し、将来の変更やコードのリファクタリングを恐れます。

インターフェイスの定義は、本当に必要なためです。実際、単純なプロパティを設定して取得する必要がある場合（多くのロジックがないため、メンバーが短くなります）、それは可能です。しかし、実際のニーズを別の方法で分析できる場合、より直感的なインターフェイスを定義しないのはなぜですか？

質問に本当に答えるために、もちろんそれはいいえです、そして、理由は非常に明白です：方法/プロパティ/ whatelseはそれが必要なもののために定義されなければなりません。空の仮想関数であっても存在する理由があります。