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

Desculpe, mas eu discordo.

• Se você não tiver um bom conjunto de habilidades em matemática, esses nomes serão mais confusos e muito menos legíveis em código.
• "O código geralmente está sendo escrito com o eixo + direção ou coordenadas xyz em mente, não uma direção cardinal (" 5 blocos oeste + 1 sul ")." - Esse código geralmente simplesmente modifica as coordenadas x / y / z diretamente, não usa o enum.
• Todos que eu conheço, mesmo os não modders, coordenam com esse mapeamento de direção cardinal em mente, simplesmente usando-os para se referir a suas distâncias relativas, digamos.

Acho que isso está sendo excessivamente rígido.

Além de cima / baixo, nunca tive que referir explicitamente qualquer uma das outras direções, então eu consideraria isso um não problema. É raro ver algo que funciona de maneira diferente em diferentes direções horizontais, com essa direção sendo codificada. Talvez exceto algum switch ... caso em todas as direções existentes, mas em ambos os casos você ainda não precisa saber como essas direções mapeiam para as coordenadas, porque há métodos úteis mais do que suficientes lá.

E também é um enum, onde provavelmente não é uma boa ideia renomear as entradas. Nomes de string em bytecode correspondem diretamente ao que os nomes de campo deveriam ser, há uma boa chance de confundir descompiladores e talvez até IDEs.

Sim, esse também é um fator importante. valueOf () para Direction retorna os cardeais, então Mojang realmente se refere a eles internamente.

Existem geralmente 4 contextos / usos para os revestimentos horizontais:

• iterando tudo
• opostos (interação do vizinho, worldgen)
• coordenar deltas (por exemplo, código de movimento da entidade)
• eixo (ver usos da classe aninhada eixo)

Os opostos são ligeiramente mais claros com a notação do eixo devido ao mesmo prefixo. Os deltas de coordenadas favorecem fortemente a notação do eixo, a.getX () - b.getX () se relaciona obviamente com XN / XP, mas não tanto para oeste / leste. Os eixos também são X / Y / Z, não norte-sul / oeste-leste / cima-baixo.

"conjunto de habilidades muito bom em matemática" -> são deslocamentos de coordenadas básicos / eixo direcionado, isso não é difícil ou ilegível. Ao contrário, "oeste" é ilegível se o código em torno dele trabalhar com coordenadas e você tiver que examinar sua relação de coordenadas primeiro.

"Esse código geralmente simplesmente modifica as coordenadas x / y / z diretamente" -> os métodos de deslocamento / movimento em BlockPos discordam. Você realmente faz essas modificações diretas por causa de quão pouco clara é a relação com os nomes atuais

Renomear os campos enum não é um problema técnico, eles são chamados de af em nomes mojang. Eu acho que eles são ruins o suficiente quando é importante não atender às escolhas de nomes de Mojang também.

Eu simplesmente não consigo encontrar um único caso em que norte / sul / oeste / leste façam sentido além de parecer um pouco menos matemático.

Renomear os campos enum não é um problema técnico, eles são chamados de af em nomes mojang.

Incorreta. O nome enum é preservado apesar da ofuscação para fazer as chamadas valueOf funcionarem, mesmo pela configuração do Proguard de Mojang. Esses são nomes que conhecemos .

Os campos enviados são chamados de af, assim como estamos renomeando os campos. Como a renomeação funciona para Mojang, também funcionaria para nós.

Grande não de mim.

Eu também discordo, acho que isso causaria mais confusão do que vale a pena

Se qualquer coisa, eu diria NORTH_XP, SOUTH_XN, etc.

No entanto, eu realmente não vejo necessidade disso. Eu apenas ficaria com os atuais

NORTH_XP

É NORTH_ZN.

Acho que você acabou de provar o ponto de vista de Player.

Mas eu concordo com modmuss e kashike, embora eu possa ver seu ponto de forma um pouco mais claro agora e acho que é um pouco válido.

Eu não concordo e isso causaria muita confusão