Yarn: NORTH / S / W / E / U / D-> ZN / ZP / .. ..

申し訳ありませんが、私は同意しません。

• 数学に非常に優れたスキルセットがない場合、これらの名前はより混乱し、コードではるかに読みにくくなります。
• 「コードは通常、基本的な方向ではなく、軸+方向またはxyz座標を念頭に置いて記述されています（「西に5ブロック+南に1ブロック」）。」 -そのコードは通常、列挙型を使用せずに、x / y / z座標を直接変更するだけです。
• 私が知っているすべての人は、改造者でなくても、相対距離を参照するためにそれらを使用するだけで、この基本的な方向マッピングを念頭に置いて調整します。

これは厳しすぎると思います。

上/下を除いて、私は他の方向を明示的に参照する必要がなかったので、それは問題ではないと思います。 水平方向がハードコーディングされているため、水平方向が異なると動作が異なるものを目にすることはめったにありません。 たぶん、いくつかのスイッチを除いて...既存のすべての方向の場合ですが、どちらの場合でも、十分な数の便利な方法があるため、それらの方向が座標にどのようにマッピングされるかを知る必要はありません。

また、列挙型でもあり、エントリの名前を変更することはおそらくお勧めできません。 バイトコード内の文字列名は、フィールド名のあるべき姿に直接対応しているため、逆コンパイラーやIDEさえも混乱させる可能性があります。

はい、それも重要な要素です。 DirectionのvalueOf（）はカーディナルを返すため、Mojangは実際にはカーディナルを内部的に参照します。

水平方向の向きには、一般的に4つのコンテキスト/使用法があります。

• すべてを繰り返す
• 反対（隣人の相互作用、worldgen）
• 座標デルタ（エンティティ移動コードなど）
• axis（axisネストクラスの使用法を参照）

同じ接頭辞があるため、軸表記を使用すると、反対側が少し明確になります。 座標デルタは軸表記を強く支持します。a.getX（）-b.getX（）は明らかにXN / XPに関連していますが、西/東にはあまり関連していません。 軸もX / Y / Zであり、南北/西東/上下ではありません。

「数学の非常に優れたスキルセット」->それらは基本的な座標オフセット/有向軸であり、これは難しいことでも読めないことでもありません。 逆に、「西」は、その周囲のコードが座標で機能し、最初にその座標関係を調べる必要がある場合は読み取りできません。

「そのコードは通常、x / y / z座標を直接変更するだけです」-> BlockPosのoffset / moveメソッドは同意しません。 現在の名前との関係が非常に不明確であるため、実際にこれらの直接変更を行います

列挙型フィールドの名前を変更することは技術的な問題ではなく、mojang名ではafと呼ばれます。 Mojangのネーミングの選択にも対応しないことが重要な場合、それらは十分に悪いと思います。

北/南/西/東が少しマチが少ないように見える以外に意味がある単一のケースを見つけることができません。

列挙型フィールドの名前を変更することは技術的な問題ではなく、mojang名ではafと呼ばれます。

正しくない。 列挙型の名前は、MojangのProguard構成によっても、valueOf呼び出しを機能させるための難読化にもかかわらず保持されます。 それらは私たちが知っている名前です。

出荷されたフィールドは、フィールドの名前を変更するのと同じように、afと呼ばれます。 名前の変更はMojangで機能するため、私たちでも機能します。

私からは大したことはありません。

私も同意しません、これはその価値よりも多くの混乱を引き起こすと思います

どちらかといえば、NORTH_XP、SOUTH_XNなどです。

しかし、私はこれの必要性を本当に見ていません。 私はただ現在のものに固執するでしょう

NORTH_XP

NORTH_ZNです。

あなたはプレイヤーの主張を証明したばかりだと思います。

しかし、私はあなたの主張をもう少しはっきりと見ることができ、それはある程度有効だと思いますが、modmussとkashikeに同意します。

私は同意しません、そしてこれは多くの混乱を引き起こすでしょう