不変を暗示するために過去形（受動音声）を使用しますか？（例：Array.TransposedとArray.Transpose）

[注：以下は、FxCopルールの引用など、構文と規則が少しC＃で重いです。これは私の背景ですが、この説明の意図は言語に依存せず、使用されるコード例は一般に疑似コード。—マイク]

クラスは一般に、オブジェクトインスタンスが実際的な場所では不変であり、クラスメンバーの呼び出し結果にはできる限り副作用がないように設計する必要があることに、私たちは全員同意するでしょう。

ただし、歴史的な命名規則では、「GetSomething」、「DoSomehing」などのアクティブな音声を使用する傾向があり、クラスメンバーが実行するアクションが明確に示されているため、これは適切です。

ただし、メンバーが過去形で名前が付けられると、参照されるオブジェクトに影響を与えることなく値が返されることを暗示することで、時々（または場合によっては）メリットが得られると考え始めています。

たとえば、配列を転置するメソッドの場合、現在の命名スタイルではおそらく 'Array.Transpose'と呼ばれますが、このメンバーが参照されたオブジェクトを転置せずに新しい配列を返す場合、それを 'Array.Transposed'と呼ぶと思います'はより正確になり、プログラマにわかりやすくなります。

'Array.Transpose（）'メソッドを使用する場合、誤って次のようなコードを使用しようとする可能性があります。

Array myArray = new Array(); 
myArray.Transpose();

ただし、「Transpose」メソッドが参照オブジェクトに影響を与えずに新しい配列を返す場合、このコードは何もしません。つまり、「myArray」は静かに転置されません。（「転置」がプロパティである場合、コンパイラは上記が正当ではないことをキャッチするでしょうが、FxCopガイドラインでは、変換を実行するメンバーはメソッドである必要があると述べています。）

しかし、メソッドが過去形で 'Array.Transposed'と名付けられている場合、次の構文が必要であることはユーザーには明らかでしょう。

Array myArray = new Array(); 
Array transposedArray = myArray.Transposed();

このカテゴリに当てはまると思う他の名前は、「サイズ変更」対「サイズ変更」、「シフト」対「シフト」などの名前のメンバーです。現在の時制は、参照オブジェクトに影響を与えるメンバーに使用されますが、過去形は、参照されるオブジェクトに影響を与えずに新しい値を返すメンバーに使用されます。

現在より一般的な別のアプローチは、各名前の前に「Get」または「To」を付けることですが、過去形に変更すると意味が効果的に伝わり、不要な重みが追加されると思います。

これはここの他のプログラマにとって意味がありますか、それともこの過去形のアイデアは、それを読むときにあまりにぎこちないように聞こえますか？

編集：

以下の素晴らしい議論、私は皆に感謝します。以下に、あなたのコメントとこれに対する私自身の修正された考え方に基づいて要約したいいくつかのポイントを以下に示します。

「流暢な」構文を連鎖させるメソッド

以下の説明に基づいて、参照されるオブジェクトの内部状態に影響を与えるメンバーまたは影響を与えないメンバーを明確にするために、可変クラスで使用する場合、過去形の使用はおそらく価値があります。

ただし、不変クラスの場合、これはケースの大部分になるはずです（希望するでしょう）、過去形を使用すると、構文が不必要に扱いにくくなる可能性があると思います。

たとえば、メソッドチェーンによって作成されるような「流暢な構文」では、過去形を使用するとコードが読みにくくなります。たとえば、C＃を介してLINQを使用する場合、一般的なメソッドチェーンは次のようになります。

dataSource.Sort().Take(10).Select(x => x.ToString);

過去形に変更すると、これは扱いにくくなります。

dataSource.Sorted().Taken(10).Selected(x => x.ToString);

ちなみに、LINQ式は常にソースに影響を与えずに新しい列挙を作成するため、dataSource.Sorted（）は実際にはdataSource.Sort（）よりも意味が明確です。ただし、このパラダイムを使用するときはこれを十分に認識しているため、過去形の使用は冗長であり、それを読み取る「流暢さ」が本当の意味で不便になります。

プロパティとメソッドの使用

以下で取り上げられた重要な問題は、「取得」メソッドと読み取り専用プロパティの使用に関するFxCopガイドラインに関係しています。例：FxCopルールCA1024。

そのFxCopルールでは明示的に言及されていませんが、ToXXXXXX（）メソッドは変換メソッドであるため、「To」メソッドの使用はこの根拠にも適用されるようです。また、ToArray（）の場合、メソッドは変換メソッドであり、配列を返すメソッドでもあります。

ブールプロパティの過去形の使用

一部の人は、過去形がブール値を暗示する可能性があることを示唆しました。たとえば、「成功」または「接続」プロパティ。ブールのプロパティとフィールドに「Is」、「Has」、または「Are」の使用を強調する以下のレトルトは正しいと思います。過去形もこの点で役立ちますが、「Is」接頭辞を使用する場合ほどではありません。ブール値のプロパティとフィールドに過去形を使用してもかまいませんが、役立ちますが、名前の前に「Is」、「Has」、または「Are」を付けることがさらに重要だと思います。

全体的な結論は？

Tranpose（）とTransposed（）の問題については、 'skizzy'は適切だと思います。これは、変化するアクションではTranspose（）、変化しない結果ではGetTransposed（）であることを示唆しています。これにより、100％明確になります。しかし、繰り返しになりますが、これは配列などの変更可能なクラスにのみ当てはまると思います。

不変クラスの場合、特に流暢なメソッドチェーン構文が使用される可能性がある場合、この構文は不必要に扱いにくくなると思います。たとえば、次を比較します。

var v = myObject.Transpose().Resize(3,5).Shift(2);

に：

var v = myObject.GetTransposed().GetResized(3,5).GetShifted(2);

うーん...実際、ここでも、結果がソースに影響を与えないことが100％明確になっているようですが、よくわかりません。

よく知られているLINQのようなパラダイムでは、 "Get"や過去形を使用する必要はありませんが、新しいAPIの場合、最初はある程度の価値があると思います。APIに不変オブジェクトのみが含まれている場合、ユーザーがこれを理解すると、「取得」や過去形の使用は読みやすさだけを低下させます。

簡単な答えはここにはないと思います。API全体について考え、慎重に選択する必要があると思います。

-マイク

ちょっと緊張した感じがします。私はあなたがその単語を形容詞であることを意図していたと思います。

ここにあなたが求めた問題に対する私の提案があります：の代わりにTranspose()と呼んでくださいGetTransposed()。こうすることで、何かを受け取り、オブジェクトを変更していないことがわかります。

それは確かに理にかなっています。

私の意見では、あなたが話していることは、APIまたはライブラリを設計するときの一般的なルールとして解釈されるべきです。その場合にのみ、システムがすべてのクラスで一貫していれば、具体的なメリットが得られます。

別の問題は、多くの場合、インターフェースのユーザーは、結果がどのようにして達成されるかについてまったく気にしないということです。

Transpose（）は現在のオブジェクトを転置しますか？Transpose（）は新しい転置インスタンスを作成し、それへの参照を返しますか？または、おそらく一度転置して、結果をコピーにキャッシュし、現在のオブジェクトに影響を与えることなく、後続の呼び出しでそれを返しますか？

ユーザーはしばしば転置された結果を取得したいだけです。そのため、提案している命名規則を気にする人は多くありません。

しかし、それ自体では、それは有効な提案です。

私は強く反対します。過去時制は扱いにくく、一般的には使用されません（それ自体は、それを好まないのに十分な理由です）。

メソッドが呼び出されたオブジェクトを変更した場合、それ自体は返されません。これにより、オブジェクトが変更されたことが明確になります。

同様に、メソッドが呼び出されたオブジェクトを変更せず、代わりに新しいオブジェクトを構築する場合、メソッドは同じタイプのオブジェクトを返します。これは明確ですでに一般的な慣例です。

私の意見では、メソッドシグネチャは、メソッドが新しいオブジェクトを返すか、呼び出し先を変更するかを示すために、より明確で一般的に使用されている規則です。

合理的に聞こえますし、前例があります— Pythonにはとの両方がlist.sort()ありsorted(seq)ます。1つ目はメソッドで、もう1つは反復可能オブジェクトに作用してリストを返す関数です。

Scalaコレクションライブラリには、過去形のメソッドがいくつかあります。

• grouped戻りのチャンクのシーケンスの要素で反復イテレータn要素
• sorted コレクションのソートされたバージョンを返します
• updated 1つの要素が変更されたコレクションの新しいバージョンを返します

ただし、Scalaのコレクションライブラリは非常に豊富であるため、これが意識的な決定なのか、名前が足りなくなったのかはわかりません。たとえば、groupByとsortByメソッドもありupdate、コンパイラが割り当てを書き換えるため、メソッドは特別です

foo(bar) = baz

に

foo.update(bar, baz)

スカラ座の古いバージョンでは、実際にやった使用をupdate不変コレクションのために、しかし持つupdateあなたは明らかに例えば不変のマップ内のエントリはものになるだろう「更新」ので、何かに戻り値を代入する必要があるため、新しいバージョンの復帰を代わりに変異することは、非常に厄介ですお気に入り

val newMap = oldMap(key) = value // HUH ??!!??

さて、

val newMap = oldMap.updated(key -> value)

良い型システムを持つ言語では、型は通常、ルーチンが引数を変更するかどうかを教えてくれます。たとえば、Haskellでは、不変バージョンのタイプは次のようになります。

transpose :: Array -> Array

可変バージョンは次のようになります

transpose :: State Array

渡された時制でメソッド/プロパティを見つけたら、すぐにブール値を返すと思います。あなたの提案は論理的に理にかなっているかもしれませんが、それは奇妙でぎこちないようです。なぜそれが理にかなっているのかを誰かに説明しなければならない場合、それはおそらく良い慣例ではありません。

私は不変の過去の変数名の大ファンではありません-それはやや珍しい慣習であり、それは特に英語の文法があまり得意ではない人（そして私は半分冗談です）にとって混乱を引き起こすと思いますそこ...）

また、この慣例により、過去形を使用してより重要と思われる何かを表す機会がなくなります。たとえば、「処理されたアイテム」などの説明されたオブジェクトの状態の説明は、コレクション内のアイテムがすでにこれは、伝えるべき重要な論理情報です。

より良いアイデア：すべてを不変にする。次に、特別な言語の区別は必要ありません。自分がしたいって分かってるんでしょ ：-）