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

죄송하지만 동의하지 않습니다.

• 수학에 능숙하지 않은 경우 이러한 이름은 코드에서 더 혼란스럽고 가독성이 떨어집니다.
• "코드는 일반적으로 기본 방향("서쪽 5블록 + 남쪽 1")이 아니라 축+방향 또는 xyz 좌표를 염두에 두고 작성됩니다." - 해당 코드는 일반적으로 열거형을 사용하지 않고 x/y/z 좌표를 직접 수정합니다.
• 내가 아는 모든 사람은 모더가 아니더라도 이 기본 방향 매핑을 염두에 두고 단순히 상대 거리를 참조하는 데 사용합니다.

이것은 지나치게 엄격하다고 생각합니다.

위/아래를 제외하고는 다른 방향을 명시적으로 참조할 필요가 없었으므로 문제가 되지 않는다고 생각합니다. 하드코딩된 방향과 함께 다른 수평 방향에서 다르게 작동하는 것을 보는 것은 드뭅니다. 기존의 모든 방향에 대한 일부 스위치...케이스를 제외하고는 있지만 두 경우 모두 해당 방향이 좌표에 매핑되는 방법을 알 필요가 없습니다. 왜냐하면 거기에 유용한 방법이 충분하기 때문입니다.

또한 항목의 이름을 바꾸는 것은 좋은 생각이 아닌 열거형이기도 합니다. 바이트코드의 문자열 이름은 필드 이름이 무엇이어야 하는지 직접적으로 대응하므로 디컴파일러와 IDE를 혼동할 가능성이 높습니다.

네, 그것도 중요한 요소입니다. 방향에 대한 valueOf()는 카디널을 반환하므로 Mojang은 실제로 내부적으로 카디널을 참조합니다.

수평면에는 일반적으로 4가지 상황/용도가 있습니다.

• 모두 반복
• 반대 (이웃 상호 작용, worldgen)
• 좌표 델타(예: 엔티티 이동 코드)
• 축(축 중첩 클래스 사용 참조)

동일한 접두사로 인해 축 표기법으로 반대가 약간 더 명확합니다. 좌표 델타는 축 표기법을 강력하게 선호합니다. a.getX() - b.getX()는 분명히 XN/XP와 관련되지만 서쪽/동쪽에는 그다지 관련이 없습니다. 축은 또한 남북/서-동/상하가 아닌 X/Y/Z입니다.

"수학에서 아주 좋은 스킬셋" -> 기본 좌표 오프셋/방향 축이며, 어렵거나 읽을 수 없습니다. 반대로 "서쪽"은 주변 코드가 좌표와 함께 작동하고 먼저 좌표 관계를 확인해야 하는 경우 읽을 수 없습니다.

"그 코드는 일반적으로 x/y/z 좌표를 직접 수정합니다." -> BlockPos의 오프셋/이동 방법은 동의하지 않습니다. 현재 이름과의 관계가 얼마나 불분명하기 때문에 실제로 직접 수정을 수행합니다.

열거형 필드의 이름을 바꾸는 것은 기술적인 문제가 아니며 mojang 이름에서는 af라고 합니다. Mojang의 이름 지정 선택을 수용하지 않는 것이 중요한 곳에서는 그것들이 충분히 나쁘다고 생각합니다.

나는 단순히 약간 덜 수학적으로 보이는 것 외에는 북쪽/남쪽/서쪽/동쪽이 의미가 있는 단일 사례를 찾지 못했습니다.

열거형 필드의 이름을 바꾸는 것은 기술적인 문제가 아니며 mojang 이름에서는 af라고 합니다.

잘못된. 열거형 이름은 Mojang의 Proguard 구성에서도 valueOf 호출이 작동하도록 난독화에도 불구하고 보존됩니다. 그것들은 우리가 알고 있는 이름입니다.

필드 이름을 바꾸는 필드를 af라고 합니다. 이름 바꾸기는 Mojang에서 작동하므로 우리에게도 효과적입니다.

나에게서 큰 아니.

나도 동의하지 않는다. 나는 이것이 가치보다 더 많은 혼란을 야기할 것이라고 생각한다.

무엇이든 NORTH_XP, SOUTH_XN 등이라고 말하고 싶습니다.

그러나 나는 이것이 정말로 필요하다고 생각하지 않습니다. 나는 그냥 현재의 것들에 충실할 것이다

NORTH_XP

NORTH_ZN입니다.

나는 당신이 방금 Player의 요점을 증명했다고 생각합니다.

그러나 나는 modmuss와 kashike에 동의합니다. 비록 지금 당신의 요점이 좀 더 명확하게 볼 수 있고 그것이 어느 정도 타당하다고 생각합니다.

나는 동의하지 않으며 이것은 많은 혼란을 일으킬 것입니다