質問

スタイルに関しては常に「正しい方法」 (「Python 的」な方法) がある Python のバックグラウンドを持つ私は、Ruby にも同じことが存在するのではないかと疑問に思っています。私は独自のスタイル ガイドラインを使用してきましたが、ソース コードをリリースすることを考えており、存在する可能性のある暗黙のルールに準拠したいと考えています。

明示的に入力するのが「Ruby のやり方」ですか return メソッドで?ありとなしでそれが行われるのを見てきましたが、それを行う正しい方法はありますか?もしかしたら権利があるのか​​も 時間 それをするために?例えば:

def some_func(arg1, arg2, etc)
  # Do some stuff...
  return value # <-- Is the 'return' needed here?
end
役に立ちましたか?

解決

古い(および&quot; answered&quot;)質問ですが、回答として2セントで投げます。

TL; DR-する必要はありませんが、場合によってはコードをより明確にすることができます。

明示的な戻り値を使用しないことは「Rubyの方法」かもしれませんが、見慣れないコードで作業しているプログラマーや、Rubyのこの機能に慣れていないプログラマーにとっては混乱を招きます。

やや不自然な例ですが、イメージングにはこのような小さな機能があり、渡された数値に1を追加して、インスタンス変数に割り当てます。

def plus_one_to_y(x)
    @y = x + 1
end

これは、値を返す関数であるかどうかを意味していましたか?開発者が何を意味したかを言うのは本当に難しいです。両方ともインスタンス変数を割り当て、割り当てられた値も返すからです。

かなり後で、別のプログラマー(実行されたコードの最後の行に基づいてRubyがどのように戻るかをよく知らない)がやって来て、ロギング用の印刷ステートメントを入れたいと考え、関数がこれになります...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
end

現在、戻り値が期待されるものがあれば関数は壊れています。戻り値が期待されていない場合は問題ありません。明らかにコードチェーンのさらに下のどこかで、これを呼び出すものが戻り値を期待している場合、期待するものを取り戻せないので失敗します。

今、本当の問題はこれです:戻り値を本当に期待しているものはありますか?これは何かを壊したかどうか?将来、何かを壊すでしょうか?知るか!すべての呼び出しの完全なコードレビューのみが通知されます。

したがって、少なくとも私にとって、ベストプラクティスのアプローチは、重要な場合は何かを返すことを非常に明確にするか、そうでない場合は何も返さないことです。

したがって、小さなデモ関数の場合、値を返すことを想定して、このように記述されます...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    return @y
end

そして、プログラマーにとって値を返すことは非常に明確であり、気付かないうちに破ることははるかに困難です。

別の方法として、このように記述してreturnステートメントを省略することもできます...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    @y
end

しかし、なぜ「return」という単語を除外するのですか?単にそこに入れて、何が起こっているのかを100%明確にしてみませんか?文字通り、コードの実行能力に影響はありません。

他のヒント

いいえ。通常、優れたRubyスタイルでは、アーリーリターンに対して明示的なリターンのみを使用します。 Rubyは、コードのミニマリズム/暗黙の魔法に優れています。

それは、明示的なリターンが物事をより明確にしたり、読みやすくしたりしても、何も害を与えないということです。

個人的に return キーワードを使用して、機能メソッドと呼ばれるもの、つまり主に戻り値のために実行されるメソッドと、手続きメソッドは主に副作用のために実行されます。そのため、戻り値が重要なメソッドでは、追加の return キーワードを取得して、戻り値に注意を引きます。

メソッドを呼び出すときに同じ区別を使用します。関数型メソッドは括弧を取得しますが、手続き型メソッドは取得しません。

最後に大事なことを言い忘れましたが、私はブロックでもその区別を使用します:機能ブロックは中括弧を取得し、手続き型ブロック(つまり「やる」ブロック)は do / end <を取得します/ code>。

しかし、私はそれについて宗教的ではないようにしています:ブロックでは、中括弧と do / end は異なる優先順位を持ち、明示的な括弧を追加して式、私はちょうど他のスタイルに切り替えます。メソッド呼び出しについても同じことが言えます。パラメーターリストの周りに括弧を追加すると、コードが読みやすくなる場合は、問題のメソッドが手続き型であっても実行します。

実際に重要なことは、次のものを区別することです。

  1. 関数 - 戻り値を取得するために実行されるメソッド
  2. プロシージャ - 副作用のために実行されるメソッド

Ruby にはこれらを区別するネイティブな方法がないため、プロシージャを作成する際に脆弱になります。 side_effect() そして別の開発者は、プロシージャの暗黙的な戻り値を悪用することを決定します (基本的に、それを不純な関数として扱います)。

これを解決するには、Scala と Haskell の本から 1 枚取り出して、 手順 明示的に返す nil (別名 Unit または () 他の言語で)。

これに従う場合は、明示的に使用します return 構文かどうかは単に個人的なスタイルの問題になります。

関数とプロシージャをさらに区別するには、次のようにします。

  1. 機能ブロックを中括弧で書き、手続き型ブロックを中括弧で書くという Jörg W Mittag の素晴らしいアイデアをコピーしてください。 do/end
  2. プロシージャを呼び出すときは、次を使用します (), 一方、関数を呼び出すときは、

Jörg W Mittag は実際にはその逆、つまり回避を提唱していることに注意してください。 ()プロシージャの場合 - ただし、特にアリティが 0 の場合、副作用のあるメソッド呼び出しを変数と明確に区​​別できるようにする必要があるため、これはお勧めできません。を参照してください。 メソッド呼び出しに関する Scala スタイル ガイド 詳細については。

スタイルガイドでは、すべきではないt最後のステートメントで return を使用する。 最後のものではない場合は引き続き使用できます。これは、コミュニティが厳密に従う規則の1つです。Rubyを使用している人とのコラボレーションを計画している場合は、そうする必要があります。


とはいえ、明示的な return を使用する主な論点は、他の言語から来た人々にとって混乱を招くことです。

  • 第一に、これはRubyに完全に限定されているわけではありません。たとえば、Perlには暗黙的な戻り値もあります。
  • 第二に、これが当てはまる人々の大半はアルゴル語から来ています。これらのほとんどは、Rubyよりも&quot;低レベル&quot; であるため、何かを成し遂げるためには、より多くのコードを記述する必要があります。

Javaのメソッドの長さ(ゲッター/セッターを除く)の一般的なヒューリスティックは、 1画面です。その場合、メソッド定義が表示されないか、どこから戻るかをすでに忘れている可能性があります。

一方で、Rubyでは lessメソッドに固執するのが最善です10行より長い。それを考えると、明確に暗示されているのに、なぜ彼は10%ほど多くのステートメントを記述しなければならないのか疑問に思うでしょう。


Rubyには void メソッドがなく、すべてがはるかに簡潔であるため、明示的な return sを使用する場合は、利点をまったく持たずにオーバーヘッドを追加するだけです。 。

私はベン・ヒューズに同意し、ティム・ホルトには同意しません。質問はPythonがそれを行う決定的な方法に言及し、Rubyに同様の標準があるかどうかを尋ねるからです。

実行します。

これは言語の非常によく知られた機能であり、ルビーの問題をデバッグすることを期待される人は誰でも合理的にそれを知ることが期待されるはずです。

ほとんどの場合、どのスタイルを好むかは問題です。メソッドの途中から戻る場合は、キーワードreturnを使用する必要があります。

ベンのように言った。 「ルビーメソッドの戻り値は関数本体の最後のステートメントの戻り値である」という事実により、ほとんどのルビーメソッドでreturnキーワードがめったに使用されません。

def some_func_which_returns_a_list( x, y, z)
  return nil if failed_some_early_check


  # function code 

  @list     # returns the list
end
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top