問題タブ [rubocop]

私の Rails アプリでは、Rubocop問題をチェックするために使用しています。今日、次のようなエラーが表示されましたAssignment Branch Condition size for show is too high。これが私のコードです:

これは何を意味し、どうすれば修正できますか?

私は自分の Ruby コード、特に Ruby のイディオムごとにスタイルを整えるという点で、自分の Ruby コードを改善するために取り組んでいます。私は次の方法を持っています：

Rubocop はこれについて不平を言い、次のようにすべきだと言っています。

「2 レベル以上のブロックの入れ子は避けてください。」

具体的には、次の行を参照しています。

ただし、これが「スタイル違反」である理由についてはまったく明確ではありません。これを「修正」するために行うことは、少なくとも私の見解では、コードが少し面倒になるようです。

なぜそれがスタイル違反なのか理解できないと私が言うとき、Ruboco がどうやら私がif...if...ifソート構造を持つべきではないと感じていることは理解できます。しかし、なぜそれが間違っているのかわかりません。

ある種のガード句を使用して、このコードの最初の if 条件をおそらく取り除くことができると考えていましたが、コードが機能しないため、それを行うことはできません。たとえば、コードを次のように変更しました。

ただし、エラーは発生しませんが、これによりコードが意図したとおりに機能しなくなります。代わりにbreakandも試してみました。returnnext

したがって、このコードを、Rubocop が文句を言わずに読み取り可能な形にする方法がわかりません。その副次的な問題として、確実に動作するコードがある場合でも、「Ruby のスタイリング」に多くの時間を費やしているように感じます。スタイルが違反である理由を理解できる限り、私は気にしませんが、ここではそれを見るのに苦労しています。そうは言っても、私は確かに、このようなものに対する直感を構築するには長い道のりがあることを学びました.

上記の問題に関して、誰かアイデアはありますか？

私はいくつかの発見に以下の更新を提供しました...

現在のコードにあるメソッドは次のとおりです。

Rubocop がこれを嫌う理由は 3 つあります。

イテレーションをスキップしたくないので、なぜ使用するのかまったくわかりませんnext。このコードでは、反復をスキップすることが理にかなっている場合はありません。

他の苦情に移ると、このメソッドの先頭で、既に 1 つのアクション ( への呼び出しparse_conditions) が分割されていることがわかります。への呼び出しもありますsearch_data_text。ここでの私の唯一のポイントは、それが理にかなっていると思われる場合にモジュール化しようとしたことです。

その大きなsearch_conditions.eachブロックを別のメソッドに移動したとしても、Rubocop は新しいメソッドも長すぎると文句を言うでしょう。これは、 2 番目のメソッドが呼び出す3 番目のメソッドをさらに追加することを意味すると思いますか? それは私には奇妙に思えます。というか、あまり分岐しなくていいということなのかな。しかし、なぜ分岐が悪いのでしょうか? 他の構造 (case...when など) に切り替えても、まだ分岐しています。また、ネストされた配列、シンボルを含む配列、またはハッシュでは処理が異なるため、これらの条件をテストする必要があります。

このような問題を見て、効果的で効率的な解決策を見つけられるように直感を構築しようとしています....しかし、私がやっていることは、ひどく非効率的で時間の無駄です. 私のコードが悪い理由がわからないので、そのトレードオフが心配です。

これを試してみて、上記のメソッドを読みやすさの外観を維持しながらRubyistが好むスタイルガイドラインに適合する状態にする方法を理解するのを手伝ってくれませんか?

---------------------- 更新 ----------------------

私が思いつくことができる最高のものはこれです：

このcheck_conditionsメソッドは、Rubocop にはまだ長すぎ、分岐条件のサイズが大きすぎます。

私が見る限り、私がチェックしたところはどこにも違いを示すことができませんでしたが、できる唯一のことは、おそらく配列とハッシュのチェックからメソッドを作成することです。つまり、各if条件はcheck_conditions独自のメソッドを取得します。しかし、それは私には不必要にばかげているように思えます。私は基本的にロジックを分解し、変数をさまざまなメソッドに渡します。これは、メソッド数を任意の値未満に保つことができるようにするためです。

これは、デザインを行う方法として、私にはかなり間違っているように感じます。しかし、ロジックを変更して必要なことを達成できるようにする方法はわかりませんが、メソッドごとに 7 行未満で実行できます。

RuboCop から長すぎると報告されたメソッドがあります。メソッドごとに 7 行しか許可されていません。問題のある方法は次のとおりです。

トップ条件をガード句に変換するつもりでしifたが、その方法がわかりません。

これに7行目と8行目を組み合わせてみました：

しかし、それは間違いなく機能しません。

RuboCop 違反をアクティブのままにすることも、許容範囲を変更することもできません。

コマンドを実行しようとすると、成功した場合は続行され、失敗した場合はエラーが発生し、コマンド出力がコンソールに送信されます。

コードは正しく機能しますが、rubocop は気に入りません。このコードのスタイルを改善し、同じ機能を提供する最善の方法は何ですか?

現在のブランチとマスターの間で変更されたファイルに対して Rubocop スタイル チェッカーを実行するspec/lint/rubocop_spec.rbを作成しました。これは、ローカルでテストする場合は機能しますが、ビルド サーバー Circle.ci でテストを実行する場合は機能しません。問題のブランチのみがダウンロードされているためと思われるため、マスター間の違いは見つかりません。よりも良い方法はありgit co master && git pull origin masterますか？変更されたファイルを一覧表示するために Github API にクエリを実行できますか?