基本方向 (n/s/w/e) 在 F3 之外很少使用 (/no?)。 编写代码时通常会考虑轴+方向或 xyz 坐标，而不是基本方向（“西 5 个街区 + 南 1 个”）。
轴+符号和基本方向之间的映射是由 Mojang 任意选择的，并且必须由开发人员在当前命名方案的每个特定用途中查找或记住。
在旋转坐标系中谈论轴+目录也更清晰。 Y 轴已旋转 90° 指向侧面听起来比现在指向侧面的“向下”更合理。
为了解决这个问题，Facing 中的字段应该重命名为 XP/XN/YP/YN/ZP/ZN，其中第一个字母是轴，第二个是方向。 其他类也可能有成员仍在使用需要更改的基本方向名称。
sfPlayer1
所有11条评论
对不起，但我不同意。
- 如果您没有很好的数学技能，这些名称在代码中会更加混乱且可读性更差。
- “编写代码时通常会考虑轴+方向或 xyz 坐标，而不是基本方向（“向西 5 个街区 + 向南 1 个街区”）。” - 该代码通常只是直接修改 x/y/z 坐标，而不是使用枚举。
- 我认识的每个人，即使是非改装者，都会考虑到这个基本方向映射，简单地使用它们来指代他们的相对距离，比如说。
我认为这过于严格了。
asiekierka
于 2018-12-11
除了向上/向下，我从来没有明确引用任何其他方向，所以我认为这不是问题。 很少看到在不同水平方向上工作不同的东西，该方向是硬编码的。 也许除了一些 switch...case 所有现有的方向，但在任何一种情况下，你仍然不需要知道这些方向如何映射到坐标，因为那里有足够多的有用方法。
它也是一个枚举，重命名条目可能不是一个好主意。 字节码中的字符串名称直接对应于字段名称应该是什么，很有可能会混淆反编译器甚至 IDE。
Barteks2x
于 2018-12-11
是的，这也是一个重要因素。 valueOf() for Direction 返回基数，因此 Mojang 实际上确实像内部那样引用它们。
asiekierka
于 2018-12-11
水平面通常有 4 种上下文/用途：
- 迭代所有
- 对立面（邻居互动，worldgen）
- 坐标增量（例如实体移动代码）
- 轴（请参阅轴嵌套类的使用）
由于相同的前缀，轴符号的对立面稍微清晰一些。 坐标增量强烈支持轴符号，a.getX() - b.getX() 显然与 XN/XP 相关，但与西/东关系不大。 轴也是 X/Y/Z，不是南北/西东/上下。
“非常好的数学技能”-> 它们是基本的坐标偏移/定向轴，这并不难或不可读。 相反，如果周围的代码使用坐标，则“west”是不可读的，并且您必须先查看其坐标关系。
“该代码通常只是直接修改 x/y/z 坐标”-> BlockPos 中的偏移/移动方法不同意。 你实际上做了那些直接修改，因为与当前名称的关系有多不清楚
重命名枚举字段不是技术问题，它们在 mojang 名称中称为 af。 我认为他们在不迎合 Mojang 的命名选择方面已经足够糟糕了。
我只是找不到一个案例，除了看起来稍微不那么数学之外，北/南/西/东有意义。
sfPlayer1
于 2018-12-11
重命名枚举字段不是技术问题，它们在 mojang 名称中称为 af。
不正确。 尽管为了使 valueOf 调用工作而进行了混淆，枚举名称仍被保留，即使是通过 Mojang 的 Proguard 配置。 这些是我们知道的名字。
asiekierka
于 2018-12-11
发送的字段称为 af，就像我们重命名字段一样。 由于重命名适用于 Mojang，它也适用于我们。
sfPlayer1
于 2018-12-11
大不从我。
kashike
于 2018-12-11
我也不同意，我觉得这会造成比其价值更多的混乱
modmuss50
于 2018-12-11
如果有的话，我会说 NORTH_XP、SOUTH_XN 等。
但是，我真的不认为有必要这样做。 我只是坚持现在的
Prospector
于 2018-12-11
NORTH_XP
是 NORTH_ZN。
我认为你刚刚证明了 Player 的观点。
但是我同意 modmuss 和 kashike，尽管我现在可以更清楚地看到您的观点，并且我认为这有点有效。
asiekierka
于 2018-12-11
我不同意，这会引起很多混乱
strikerrocker
于 2018-12-14
相关问题
quat1024
·
3评论
Runemoro
·
3评论
Sollace
·
5评论
copygirl
·
6评论
haykam821
·
4评论
最有用的评论
大不从我。