Yarn: Aide vs Util vs Utils

J'aime le singulier Util le meilleur. 👍 pour Util. 👎 pour Helper, 😕 pour Utils

tbh je pourrais aller n'importe où, soyons cohérents.

Aussi, si nous avons des verbes, nous pouvons utiliser -ing (gerund), par exemple Chatting NetworkThreading , ou des noms pluriels, par exemple Projectiles Screenshots sur Helper Util etc.

Cela rend difficile certaines choses comme MathHelper -> Maths ?? Ou Util -> s ??

J'ai plaidé pour Maths il y a longtemps, étant donné que c'est une abréviation valide pour Mathematics . https://github.com/FabricMC/yarn/issues/249#issuecomment -446102638

Yarn utilise des noms en anglais américain, où Maths n'est pas une abréviation valide pour Mathematics .

Dans ce cas où ni le gérondif ni le pluriel ne s'appliquent, je suggère de revenir au suffixe Helper . Sinon préférez ing ou s , comme Texts

De plus, DrawableHelper n'est pas une classe utilitaire mais une interface fonctionnelle ou une classe abstraite avec de nombreuses méthodes d'instance pratiques

Mon problème avec la proposition de liach avec -ing et -s est qu'il est très difficile de rendre quoi que ce soit cohérent, ce qui va complètement à l'encontre du but du problème. Vous pouvez faire en sorte que les classes d'utilitaires nominaux se terminent par -s , mais vous allez avoir des exceptions : Nbts , RailPlacements , Maps ? Il serait impossible de rendre cohérent.

Nous devrions adopter une norme et nous y tenir. En regardant le vote, cela devrait être Helper ou Util , mais pas Utils .

Un argument pour Util sur Helper est que la classe Util elle-même n'a pas de sens pour être appelée Helper . Je pense que MathHelper s'appelle MathUtil ne serait pas si mal, c'est juste que tout le monde est habitué à ce qu'il s'appelle MathHelper . J'ai travaillé dans des projets où la classe d'utilitaires mathématiques s'appelait MathUtil , et ça s'est très bien passé, ça ne fait aucune différence. Le nom MathUtil n'a même pas été abordé dans le problème de renommage MathHelper .

Il y a plus de classes Util que de classes Helper actuellement, mais cela doit être pondéré par la fréquence à laquelle les classes sont réellement utilisées, donc je vais examiner cela maintenant et rendre compte des résultats .

Il semble que la majorité des gens soient pour le suffixe Helper . Par conséquent, je propose de renommer toutes les classes actuelles se terminant par Util ou Utils (sauf la classe Util elle-même) pour se terminer par Helper . Les renommages d'autres classes pour qu'elles se terminent par Helper peuvent être discutées dans des numéros distincts.

Il semble que la majorité des gens soient pour le suffixe Helper .

Non?

Oh, oups, je dois être aveugle. Ensuite, je propose de renommer toutes les classes se terminant par Helper pour qu'elles se terminent plutôt par Util .

Je propose que les suffixes soient l'œuvre du diable et que nous renommions toutes les classes se terminant par *elperer et *til pour ne pas avoir ce suffixe.

MathHelper -> Maths .

PiglinHelper -> Piglins

Yarn utilise des noms en anglais américain, où Maths n'est pas une abréviation valide pour Mathematics .

Je pensais que Maths était un terme exclusivement américain ?

MathHelper -> Mathinator

Maps ? je

Notez également que Guava (je pense que c'était Guava ?) utilise le modèle pluriel : Maps , Sets , Collections , Streams .

C'était mon problème avec l'utilisation des pluriels. Bien que les noms soient beaux, il y a trop d'exceptions. Soit parce que le mot est un nom de masse (par exemple "math") et n'a donc pas de pluriel, soit parce que le pluriel est déjà pris par une autre bibliothèque (par exemple "map"). Cela rendrait trop difficile de rester cohérent, en vainquant le point de les changer en premier lieu.

Les noms qui seraient acceptables au pluriel :

• Tampons
• Flux de données
• Tirables
• Habillages par défaut
• Mipmaps
• Nbts
• RailPlacements
• apparaît
• Contributions
• Des modèles
• Textures
• Noms de fichiers
• Projectiles
• Rechercher des cibles
• StructureTests
• Essais
• Captures d'écran
• GlAllocations

Les noms qui ne conviennent pas parce qu'ils sont des noms de masse ou qu'ils ne sont pas des noms :

• Jsons
• Mathématiques
• Als
• Glfws
• Lisse
• Dommages (le pluriel a un sens différent)
• Réseaux (il n'y a qu'un seul réseau ici)
• NetworkThreads (il n'y a qu'un seul thread réseau)
• Cryptage du réseau

Les noms qui ne conviennent pas car ils sont déjà pris :

• Enchantements
• Plans
• StatutEffets
• Potions

Noms qui ne conviennent pas pour diverses raisons :

• Rotation3s (ce nom demande plus de réflexion)
• Chats (bien que techniquement le pluriel de chat, il ne convient pas bien en tant que classe utilitaire pour "le chat", en supposant que c'est à cela qu'il sert. Si c'est pour des composants de texte, alors "Textes" serait un nom correct)
• Utils (nous ne pouvons pas le renommer en "s" lol, il vaut mieux le conserver en "Util")

Au total, 18/34 noms seraient acceptables au pluriel, ce qui signifie que nous devrions trouver de meilleurs noms pour les 16 autres. Voilà pour la cohérence.

Je serais d'accord avec l'utilisation de pluriels là où cela a du sens et en revenant à un suffixe Util où cela n'a pas de sens. Alors au moins nous avons une règle à suivre plutôt que de choisir au hasard entre "Helper" et "Util", ce que nous faisons actuellement.

@Earthcomputer NetworkThreads fonctionne bien, cependant. Ce sont des utilitaires pour travailler avec les threads réseau. Peu importe qu'il n'y en ait qu'un.

Vous pouvez être en désaccord avec moi sur un ou deux de ces points, mais ce n'est pas le point, cela ne change pas beaucoup le ratio global de 18/34.

Je dirais que Util ou Helper , les supprimer complètement n'a pas trop de sens pour moi.

Au fait, certains ne peuvent pas être nommés Util . Par exemple, DataStreamHelper n'est pas une classe util, c'est un objet qui encapsule un flux de données.