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

Entschuldigung, aber ich bin anderer Meinung.

• Wenn Sie nicht über sehr gute Mathematikkenntnisse verfügen, sind diese Namen verwirrender und im Code weniger lesbar.
• "Der Code wird normalerweise mit den Koordinaten Achse + Richtung oder xyz geschrieben, nicht mit einer Himmelsrichtung ("5 Blöcke West + 1 Süd")." - Dieser Code ändert normalerweise einfach die x/y/z-Koordinaten direkt und verwendet nicht die Aufzählung.
• Jeder, den ich kenne, auch Nicht-Modder, stimmen sich mit dieser Himmelsrichtungszuordnung ab, indem sie sie einfach verwenden, um sich beispielsweise auf ihre relativen Entfernungen zu beziehen.

Das finde ich zu streng.

Abgesehen von oben/unten musste ich nie explizit auf eine der anderen Richtungen verweisen, daher würde ich dies als kein Problem betrachten. Es kommt selten vor, dass etwas in verschiedenen horizontalen Richtungen unterschiedlich funktioniert, wobei diese Richtung fest codiert ist. Vielleicht mit Ausnahme einiger Schalter für alle vorhandenen Richtungen, aber in beiden Fällen müssen Sie immer noch nicht wissen, wie diese Richtungen den Koordinaten zugeordnet werden, da es dort mehr als genug nützliche Methoden gibt.

Und es ist auch eine Aufzählung, bei der es wahrscheinlich keine gute Idee ist, die Einträge umzubenennen. String-Namen im Bytecode entsprechen direkt den Feldnamen, es besteht eine gute Chance, dass Decompiler und vielleicht sogar IDEs verwechselt werden.

Ja, das ist auch ein wichtiger Faktor. valueOf() für Direction gibt die Kardinäle zurück, sodass Mojang intern tatsächlich so auf sie verweist.

Es gibt im Allgemeinen 4 Kontexte/Verwendungen für die horizontalen Verkleidungen:

• alles wiederholen
• Gegensätze (Nachbarinteraktion, worldgen)
• Koordinaten-Deltas (zB Bewegungscode der Entität)
• Achse (siehe Verwendungen der verschachtelten Klasse Achse)

Gegensätze sind bei der Achsennotation aufgrund des gleichen Präfixes etwas klarer. Koordinatendeltas begünstigen stark die Achsennotation, a.getX() - b.getX() bezieht sich offensichtlich auf XN/XP, aber nicht so sehr auf West/Ost. Achsen sind auch X/Y/Z, nicht Nord-Süd/West-Ost/Auf-Ab.

"sehr gute Kenntnisse in Mathematik" -> es handelt sich um grundlegende Koordinatenverschiebungen / gerichtete Achsen, dies ist nicht schwer oder unlesbar. Im Gegensatz dazu ist "west" unlesbar, wenn der Code um ihn herum mit Koordinaten arbeitet und Sie zuerst die Koordinatenbeziehung nachschlagen müssen.

"Dieser Code ändert normalerweise einfach die x/y/z-Koordinaten direkt" -> die offset/move-Methoden in BlockPos stimmen nicht überein. Sie nehmen diese direkten Änderungen tatsächlich vor, weil die Beziehung zu den aktuellen Namen unklar ist

Das Umbenennen der Enum-Felder ist kein technisches Problem, sie werden in Mojang-Namen af ​​genannt. Ich denke, sie sind schon schlimm genug, wenn es darauf ankommt, nicht auf Mojangs Namenswahl einzugehen.

Ich finde einfach keinen einzigen Fall, in dem Nord / Süd / West / Ost einen Sinn ergibt, außer etwas weniger mathematisch auszusehen.

Das Umbenennen der Enum-Felder ist kein technisches Problem, sie werden in Mojang-Namen af ​​genannt.

Falsch. Der Enum-Name wird trotz Verschleierung beibehalten, damit valueOf-Aufrufe funktionieren, sogar durch Mojangs Proguard-Konfiguration. Das sind Namen, die wir kennen .

Die Felder im Auslieferungszustand heißen af, genau wie wir die Felder umbenennen. Da die Umbenennung für Mojang funktioniert, würde sie auch für uns funktionieren.

Großes Nein von mir.

Ich bin auch anderer Meinung, ich denke, das würde mehr Verwirrung stiften, als es wert ist

Wenn überhaupt, würde ich NORTH_XP, SOUTH_XN usw. sagen.

Allerdings sehe ich die Notwendigkeit dafür nicht wirklich. Ich würde einfach bei den aktuellen bleiben

NORTH_XP

Es ist NORTH_ZN.

Ich denke, Sie haben gerade den Standpunkt des Spielers bewiesen.

Aber ich stimme Modmuss und Kashike zu, auch wenn ich Ihren Punkt jetzt etwas klarer sehen kann und ich denke, dass er einigermaßen gültig ist.

Ich stimme dem nicht zu und das würde viel Verwirrung stiften