単語が名詞と動詞の両方であるときに変数に名前を付ける方法


48

以下の一般的なガイダンスで、コーナーケースの問題に遭遇しました。

  • 変数の名詞
  • 関数の動詞

具体的には、単語があいまいな場合があります-動詞または名詞のいずれかです。また、アプリケーションについて説明している場合には、同じ文で両方の方法で使用されます。

私の意図は、数か月後にコードのセクションに戻ったときに、自分自身だけでなく将来の開発者にもプログラムが読めるようにすることです。

例の1つはbatteryです。Aにbatteryはバッテリーchargeがありcharge()ます。

両方を持つことはBattery.ChargeBattery.Charge(value)将来の開発者にとって混乱を招くと思います。

私の現在の解決策は、これらのケース(変数と関数)のいずれかまたは両方に対して異なる単語を選択することです。そのアプローチに関する私の問題は、Batteryオブジェクトの変数と関数がchargeを含む設計の議論と一致しないことBatteryです。

私の質問は、命名規則のこの競合を処理する別の/より良い方法があるかどうかです。


件名に関するいくつかの追加の読書。私の質問の特定に実際に取り組んだものはありません。


3
充電機能addChargeを簡単かつ十分に明確にします
ラチェットフリーク

2
名詞変数の前に「Current-」を付けることはできますか?だから「CurrentCharge」対「Charge()」?
ブライアンスノー

6
またはChargeLevelで現在の料金を取得する
ラチェットフリーク

5
単語を作ります。WordNetはenqueue単語とは思いませんが、Javaの動詞です。どうdoCharge?あなたの他の方法は、この接頭辞がありませんので、それはまだ対称性テストに失敗します
惨めな変数

5
「現在」=今、または「現在」=電荷の流れ。唯一の本当の解決策は、英語をより賢明な言語に置き換えることです!
-DarenW

回答:


38

同様の状況で、同義語を見つけようとします。この場合、動詞に「リチャージ」を使用します。「再」は少し冗長ですが、意味は明確です。バッテリーの残りの充電に単純な「充電」を使用することは、物理単位を指定しないため、あいまいです。私は「availableAmpHours」、「hoursUntilRecharge」などを好むでしょう。単位は、アプリケーションにとって便利なものに依存します。

私の個人的な好みは、状態を変更する機能にのみ動詞を使用することです。変化しない関数には名詞を使用します。それはあなたの視点に依存すると思います。マシンレベルでは、変化しない関数は何かをしますが、モデルレベルではしません。


2
ユニットの優れた点。この場合、実行中の分析に応じてユニットが変わる可能性があるため、ユニットは明示的に省略されます。つまり、異なる時間スケールを使用しており、バッテリーは分析のスケールの観点からその動作を調整します。

1
高価で、変化しない関数には動詞が好きです。たとえば、データベースでクエリを実行する関数。
ブライアン

20

これを捨てるだけですが、多分この名前のあいまいさのインスタンスの解決策は、バッテリーからその機能を完全に削除することです。バッテリーを自己充電するのを見たことがないので、BatteryChargerクラスを用意する方が理にかなっています。これにより、懸念をより切り離し、アクションをより明確にすることができます。

battery.Charge(50)batteryCharger.Charge(battery, 50)

私にとって、2番目の形式ははるかに理解しやすく、すべてのバッテリークラスに散らばるのではなく、すべての「充電」コードを1か所に保持します。


6
それは悪い考えではありませんが、この場合Batteryはバッテリー+充電システムの抽象化です。このアプリでは、2つの側面を別々のオブジェクトに分割する必要がないためBattery、便宜上1つ(別名)にロールされます。最終的に、充電式バッテリーの物理学は、充電を受け入れる何らかの機能を持っていることを指示します。

その場合、私はケビン・クラインの答えがあなたが探しているものであることを提出します。明確にするために、変更関数にはRechargeとDischargeを使用し、プロパティ名にはChargeを使用します。おそらくChargePercentも良いでしょう。
モータラペマン

おそらくJavaプログラマーですか?これは明らかに、自分自身を繰り返さないことの違反です。実際、パラメーター「50」以外のすべてを繰り返しています。試した場合、DRY違反のより悪い例は思いつきませんでした。
箱入り

@boxed私の例を取り上げていますか?実装していないときにDRYに違反していると主張する方法がわからないためです。私は固い原則の大きな支持者であり、あなたがどのようにしてその結論に至ったのか見ていません。
モータラペマン

不必要なBatteryChargerクラスを作成することでDRYに違反しているため、何らかの理由でバッテリーの状態が変化します。そのため、BatteryChargerは入力を受け入れ、すぐにBatteryに渡します。
ケビンクライン

9

二重の意味を避ける

意図的に複数の意味を持つ単語を選択しましたが、その最初の決定が問題です。プログラマーにとって問題のある単語はたくさんあります。別の例は次のようになりますphone。あなたはphone誰か、またはphoneあなたのポケットに入れることができます。

ゲッターとセッターを使用する

ほとんどのオブジェクトの標準の命名は、プロパティのゲッター/設定メソッドです。

Battery.Charge            // would be a property
Battery.setCharge(value)  // would set the property
Battery.getCharge()       // would get the property

プロパティは名詞ではなく状態です

オブジェクトプロパティを名詞として分類するのは間違っていると思います。変数は状態と考えることもできます。それらは、その存在のローカルスコープに関連する状態です。

それらが保持する値を名詞として説明することもできますが、それがすべての場合に当てはまるかどうかはわかりません。

OOPの用語では、オブジェクトプロパティはそのオブジェクトの状態を表します。あなたの場合、BatteryはオブジェクトでありCharge、状態です。したがって、それはオブジェクトのプロパティになりますが、これは使用方法のコンテキストに依存します。

Chargeバッテリーを使用できるようにする必要Chargeがあり、現在のバッテリーが何かを知る必要がある場合は、問題があります。

スコープを使用してコンテキストを強制する

コンテキストとは、メソッドまたはプロパティに伝えることを意図している単語の意味を明確にするものです。スコープは、オブジェクトの外部からプロパティ/メソッドのアクセシビリティを設定しています。

Batter._charge            // a hidden private property
Battery.setCharge(value)  // would set the private property
Battery.getCharge()       // would get the private property
Battery.Charge()          // would perform the Charge action

メソッドは動詞です

オブジェクトのメソッドは動詞として説明できますが、アクションという言葉の方が適しています。OOPの用語では、メソッドを使用してオブジェクトに対してアクションを実行します。オブジェクトの外部からオブジェクトのプロパティを変更するのは悪い方法です。状態を変更するために必要なアクションを実行するメソッドを呼び出すことをお勧めします。

単語Chargeは動詞ですが、名詞でもあります。アクションのメソッドを呼び出すために使用すると、動詞が使用されていることが明らかになりBattery.Charge(....)ます。

しかし、コンテキストは非常に重要です。単語Charge()は動詞ですが、ほど意味がありませんstartCharging()

以下のための有効な方法はBattery含めることができChargingDischargingsetChargegetChargehasChargeDischargeCharged

シンプルな1ワード法は、多くの場合、明示的に明確に彼らの行動を述べるませんが、そこにいくつかの例は次のようにしているopencloseどこ少し説明が必要です。

そのため、これらのタイプのプロパティ/メソッドに名前を付ける方法に関して、実際には正しい答えはありません。混乱がないように、上記の手法を賢く使用する必要がある場合を除きます。


2
記録のために、クライアントはあいまいな用語を使用している人です。はその混乱を作成しませんでした。:-)このような状況に足を踏み入れるのは私だけではないかもしれないと思ったので、質問を持ち出しました。答えにはいくつかの有効なポイントがあります。この特定のケースでは、StartCharge()それEndCharge()が意味する時間の細分性で作業していません。実際、その用語はバッテリーシステムの処理に大きなオーバーヘッドを追加します。各間隔で、Charge()またはのいずれかDischarge()です。

1
主な問題は、クライアントが使用している用語と内部プログラミングのセマンティクスを同期させることです。 Chargeたまたまこのドメインで最もよく理解されているあいまいな単語です。他にもいくつかあります。


4

動詞の場合、Charge大丈夫だと思います。名詞の場合、getCurrentChargeLevelあなたのために働くでしょうか?


わからない。C#を使用しているため、別個の関数を必要とせずに、プロパティでgetおよびsetを宣言できます。それに関係なく、私は自分が書いたものを忘れてしまえば、メンテナンスとそれがどのように見えるかを心配しています。のgetCurrentChargeLevel()内部変数を参照する必要はありませんBatteryか?その変数の名前は何ですか?

充電は電圧ですか、それともパーセンテージですか?
mhoran_psprep

1
@ GlenH7:ああ、なるほど。C#を指定しておらず、私の脳はJavaモードです。いずれにせよ、現在バッテリーに充電されている量を表す名詞については、線に沿った何かBattery.currentChargeLevelが機能する可能性があると思います。Battery.coloumbsまたはを使用してみることができますがBattery.ampereHours、それはそれほど明白ではないかもしれません
...-FrustratedWithFormsDesigner

1
@mhoran_psprep-どちらでもありません。;-)は ChargeあるEnergyあるPower(ボルトアンペア* ==ワット)時間を掛けました。したがって、この場合、料金は数字です。また、パーセントである充電状態もあります。

@FrustratedWithFormsDesigner-はい、言語に関係なくより広いコーナーケースが適用可能だと思ったため、C#を省きました。 Watt*time設計上の会話とは一致しませんが、間違いはありませんChargeLevel

0

ほとんどの場合、助動詞、副詞、または形容詞を追加することでそれらを区別するのに十分であり、実際に理解を助けることができます。バッテリーのChargeおよびCharge()の場合、DeltaCharge()は、充電または放電のいずれかを処理できる関数であることを示すことができます。

Delta(変化はあるがあいまいな場合)は、状態の変化を処理するために常に使用し、他の人に推奨する修飾子です(動詞が半自明であっても)。


0

ハンガリー記法による救助。あなたは持つことができますintChargeし、fcnCharge(value)このように混乱を回避し、3つの文字がうまく動作しますとき狂気に長い名前を追加していません、。

または、同じ名前を使用してIDEで処理することもできます。とにかく長い名前を作成することは、長い目で見れば混乱を招くかもしれません。


答えのユニークな視点のために+1。残念ながら、ハンガリー語の表記法は、コードスタイルガイドラインに従って明示的に詳細に記述されています。それがあなたの答えの潜在的なメリットを変えることはありません。ただ実際の解決策としてそれを使うことはできません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.