web-dev-qa-db-ja.com

コードで略語を使用する正しい方法はありますか？

ああ、コードの略語、すべての開発者の悩みの種。

コンセンサスはそれらに反対しているようです 、可読性が影響を受ける可能性があるため。しかし、与えられた例はしばしば "repr" for "represent" のように極端です。私はそれを極端と呼んでいます、なぜならそれは短縮する必要のない単語を非常に曖昧な意味を持つ何かに短縮するからです。

私の例を、省略形が正当化される可能性のある例として考えてください。いくつかのプロジェクションを使用するプロジェクトがあります。これは、基本的にMongoデータベースのビューです。投影法を説明的に名付けるには、パースペクティブを説明する必要があります。また、各プロジェクションには、それを機能させるためのいくつかのクラスがあり、各クラスにはプロジェクション名の後に独自の名前が付いています。

したがって、StatemachineDefinitionRelevantEventsという名前のプロジェクションがあるため（これは、プロジェクションを説明する最短の方法であるということです）、StatemachineDefinitionRelevantEventsAggregrateProjection、StatemachineDefinitionRelevantEventsReadModel、StatemachineDefinitionRelevantEventsRepositoryという名前のクラスもあります。それらは約50文字です。

変数も許可されていないため（会社のポリシー）、次のようなコードが表示されます。

StatemachineDefinitionRelevantEventsAggregrateProjection statemachineDefinitionRelevantEventsAggregrateProjection = new StatemachineDefinitionRelevantEventsAggregrateProjection(<bunch of parameters with similarly lengthy names>);

これらのクラスをいくつか続けて作成する必要がある場合は、何度も繰り返します。

私は、StatemachineDefinitionRelevantEventsのすべてのインスタンスをSDREで置き換えることにしました。 SDREがStatemachineDefinitionRelevantEventsを表し、プロジェクションの定義と目的を説明していることを、ユビキタス言語とドキュメントではっきりと指摘しています。驚いたことに、私の初期化は突然1行に収まりました。また、サフィックスは常に省略されないままであるため、SDREの意味がわからなくても、SDRERepository、SDREReadModel、およびSDREAggregrateProjectionの機能は、名前だけから解釈できるはずです。

これは、略語の正当化された「良い」使用の例ですか、それともまだ間違っていますか？チームに提案する前に、セカンドオピニオンを取得したいと思います。

c#namingclean-code
7
KeizerHarm

まず、クラスの命名が奇妙に思われます。一般的に、慣習では、最も具体的な単語から最小限の単語に移動します。例えば。 AggregateExceptionおよびFileNotFoundException。あなたの場合、それらはそうなります（これらが正しい順序であると仮定します）：

AggregrateProjectionStatemachineDefinitionRelevantEvents
ReadModelStatemachineDefinitionRelevantEvents
RepositoryStatemachineDefinitionRelevantEvents

一般に、省略形を避けることをお勧めします 。ただし、これは特に極端なケースのようです。変数名statemachineDefinitionRelevantEventsAggregrateProjectionはクラスの前に省略します（提案しているのかどうかは質問からはわかりません）。

次に、これらの短い名前は次のようになります。

aggregrateProjectionSdre
readModelSdre
repositorySdre

（注：SdreではなくSDREではなくHtmlContextではなくHTMLContextではありません）

変数も許可されていないため（会社のポリシー）、次のようなコードが表示されます。

まさにこのような理由で、言語機能の全面禁止は奇妙です。冗長な名前を付けるために、コードの全体的な可読性を損ないます。おそらく、型がステートメントの右側にある場合は、varを許可するほうが（中間点の）ルールの方が良いでしょう。

これを組み合わせて（そして賢明な行の長さを保つように注意して）、次のようになります。

var aggregrateProjectionSdre = 
    new AggregrateProjectionStatemachineDefinitionRelevantEvents(
        <bunch of parameters with similarly lengthy names>,
        <bunch of parameters with similarly lengthy names>,
        ...);

（または、誤った仮定をした場合はsdreAggregrateProjection）

Sdreを省略しても、コンテキストからどの程度明白かによっては回避できる場合もあります。

3
Durdsoft

これは、名前空間が便利な状況です。 C＃の構文はわかりませんが、次のようなものです。

Statemachine::Definition::RelevantEvents::AggregrateProjection 
Statemachine::Definition::RelevantEvents::ReadModel
Statemachine::Definition::RelevantEvents::Repository

これにより、必要な場合に完全なコンテキストを持つことができますが、コンテキストが明確である場合はそれほど冗長ではありません。あなたがすることができます：

import Statemachine::Definition::RelevantEvents as SDRE
...
SDRE::AggregrateProjection 
SDRE::ReadModel
SDRE::Repository

あるいは：

using namespace Statemachine::Definition::RelevantEvents
...
AggregrateProjection 
ReadModel
Repository

usingステートメントまたはエイリアス化されたインポートをよく非難します。なぜなら、コンテキストに精通していないかもしれないが、明確な限定されたスコープ内のさまざまなスコープの人々に略語を課すヘッダーファイルでは悪いからです。ここのすべてがStatemachine::Definition::RelevantEvents、それらは多くの混乱を取り除き、多くの読みやすさを追加します。

2
Karl Bielefeldt