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

Désolé, mais je ne suis pas d'accord.

• Si vous n'avez pas de très bonnes compétences en mathématiques, ces noms sont plus déroutants et beaucoup moins lisibles dans le code.
• "Le code est généralement écrit avec l'axe + direction ou les coordonnées xyz à l'esprit, pas une direction cardinale ("5 blocs ouest + 1 sud")." - Ce code modifie généralement simplement les coordonnées x/y/z directement, n'utilise pas l'énumération.
• Tous ceux que je connais, même les non-moddeurs, se coordonnent avec cette cartographie de direction cardinale à l'esprit, simplement en les utilisant pour se référer à leurs distances relatives, disons.

Je pense que c'est trop strict.

Mis à part le haut/bas, je n'ai jamais eu à faire explicitement référence à l'une des autres directions, donc je considérerais cela comme un non-problème. Il est rare de voir quelque chose qui fonctionne différemment dans différentes directions horizontales, cette direction étant codée en dur. Peut-être à l'exception de certains commutateurs... cas sur toutes les directions existantes, mais dans les deux cas, vous n'avez toujours pas besoin de savoir comment ces directions correspondent aux coordonnées, car il y a plus qu'assez de méthodes utiles là-bas.

Et c'est aussi une énumération, où ce n'est probablement pas une bonne idée de renommer les entrées. Les noms de chaîne dans le bytecode correspondent directement à ce que devraient être les noms de champ, il y a de fortes chances que cela confonde les décompilateurs et peut-être même les IDE.

Oui, c'est aussi un facteur important. valueOf() pour Direction renvoie les cardinaux, donc Mojang s'y réfère en fait de la même manière en interne.

Il existe généralement 4 contextes/usages pour les parements horizontaux :

• itérer tout
• opposés (interaction entre voisins, worldgen)
• deltas de coordonnées (par exemple, code de mouvement d'entité)
• axe (voir utilisations de la classe imbriquée d'axe)

Les opposés sont légèrement plus clairs avec la notation des axes en raison du même préfixe. Les deltas de coordonnées favorisent fortement la notation des axes, a.getX() - b.getX() se rapporte évidemment à XN/XP, mais pas tellement à ouest/est. Les axes sont également X/Y/Z, pas nord-sud/ouest-est/haut-bas.

"très bonnes compétences en mathématiques" -> ce sont des décalages de coordonnées de base/axe dirigé, ce n'est ni difficile ni illisible. Au contraire, "west" est illisible si le code qui l'entoure fonctionne avec des coordonnées et que vous devez d'abord rechercher sa relation de coordonnées.

"Ce code modifie généralement simplement les coordonnées x/y/z directement" -> les méthodes offset/move dans BlockPos ne sont pas d'accord. Vous effectuez en fait ces modifications directes en raison du manque de clarté de la relation avec les noms actuels

Renommer les champs enum n'est pas un problème technique, ils sont appelés af dans les noms mojang. Je pense qu'ils sont assez mauvais là où il est important de ne pas non plus répondre aux choix de nom de Mojang.

Je ne parviens tout simplement pas à trouver un seul cas où nord/sud/ouest/est a un sens autre que d'avoir l'air un peu moins mathématique.

Renommer les champs enum n'est pas un problème technique, ils sont appelés af dans les noms mojang.

Incorrect. Le nom d'énumération est conservé malgré l'obscurcissement pour que les appels valueOf fonctionnent, même par la configuration Proguard de Mojang. Ce sont des noms que nous connaissons .

Les champs tels qu'ils sont

Gros non de ma part.

Je ne suis pas d'accord non plus, je pense que cela causerait plus de confusion que cela n'en vaut la peine

Si quoi que ce soit, je dirais NORTH_XP, SOUTH_XN, etc.

Cependant, je n'en vois vraiment pas l'utilité. Je m'en tiendrais aux actuels

NORTH_XP

C'est NORTH_ZN.

Je pense que vous venez de prouver le point de vue de Player.

Mais je suis d'accord avec modmuss et kashike, même si je vois votre point un peu plus clairement maintenant et je pense que c'est un peu valable.

Je ne suis pas d'accord et cela causerait beaucoup de confusion