Yarn: Helfer gegen Util gegen Utils

Mir gefällt der Singular Util am besten. 👍 für Util. 👎 für Helfer, 😕 für Utilities

tbh Ich könnte jeden Weg gehen, lasst uns einfach konsequent sein.

Auch wenn wir Verben haben, können wir -ing (Gerundium) verwenden, z. B. Chatting NetworkThreading , oder Substantive im Plural, z. B. Projectiles Screenshots über Helper Util usw.

Das macht es schwierig für einige Dinge wie MathHelper -> Maths ?? Oder Util -> s ??

Ich habe mich schon vor langer Zeit für Maths ausgesprochen, da es eine gültige Abkürzung für Mathematics ist. https://github.com/FabricMC/yarn/issues/249#issuecomment -446102638

Garn verwendet amerikanische englische Namen, wobei Maths keine gültige Abkürzung für Mathematics ist.

In diesem Fall, in dem weder Gerundium noch Plural zutreffen, schlage ich vor, auf das Suffix Helper zurückzugreifen. Andernfalls bevorzugen Sie ing oder s , wie Texts

Außerdem ist DrawableHelper keine Utility-Klasse, sondern eine funktionale Schnittstelle oder abstrakte Klasse mit vielen praktischen Instanzmethoden

Mein Problem mit Liachs Vorschlag mit -ing und -s ist, dass es sehr schwierig ist, etwas konsistent zu machen, was den Zweck des Problems vollständig zunichte macht. Sie könnten es so machen, dass Substantiv-Hilfsklassen auf -s enden, aber dann werden Sie Ausnahmen haben: Nbts , RailPlacements , Maps ? Es wäre unmöglich, konsistent zu machen.

Wir sollten einen Standard annehmen und uns daran halten. Wenn man sich die Abstimmung ansieht, sollte das entweder Helper oder Util sein, aber nicht Utils .

Ein Argument für Util gegenüber Helper ist, dass es keinen Sinn macht, die Klasse Util Helper zu nennen. Ich denke, MathHelper MathUtil genannt zu werden, wäre nicht so schlimm, es ist nur so, dass jeder daran gewöhnt ist, MathHelper genannt zu werden. Ich habe in Projekten gearbeitet, in denen die mathematische Hilfsklasse MathUtil genannt wurde, und es war absolut in Ordnung, es macht keinen Unterschied. Der Name MathUtil wurde in der MathHelper -Umbenennungsfrage nicht einmal diskutiert.

Derzeit gibt es mehr Util -Klassen als Helper -Klassen, aber das muss danach gewichtet werden, wie oft die Klassen tatsächlich verwendet werden, also werde ich das jetzt untersuchen und über die Ergebnisse berichten .

Es scheint, dass die Mehrheit der Leute für das Suffix Helper ist. Daher schlage ich vor, alle aktuellen Klassen, die mit Util oder Utils enden (mit Ausnahme der Klasse Util selbst), so umzubenennen, dass sie mit Helper enden. Umbenennungen anderer Klassen, die auf Helper enden, können in separaten Ausgaben diskutiert werden.

Es scheint, dass die Mehrheit der Leute für das Suffix Helper ist.

Nein?

Oh, hoppla, ich muss blind sein. Dann schlage ich vor, dass wir alle Klassen, die auf Helper enden, umbenennen und stattdessen auf Util enden.

Ich schlage vor, dass Suffixe das Werk des Teufels sind und dass wir alle Klassen umbenennen, die auf *elperer und *til enden, um dieses Suffix nicht zu haben.

MathHelper -> Maths .

PiglinHelper -> Piglins

Garn verwendet amerikanische englische Namen, wobei Maths keine gültige Abkürzung für Mathematics ist.

Ich dachte, Maths wäre ein ausschließlich amerikanischer Begriff?

MathHelper -> Mathinator

Maps ? ich

Beachten Sie auch, dass Guava (ich glaube, es war Guava?) das Pluralmuster verwendet: Maps , Sets , Collections , Streams .

Das war mein Problem mit der Verwendung von Pluralformen. Obwohl die Namen schön aussehen, gibt es zu viele Ausnahmen. Entweder weil das Wort ein Massennomen ist (z. B. „math“) und daher keinen Plural hat, oder weil der Plural bereits von einer anderen Bibliothek belegt ist (z. B. „map“). Es würde es zu schwierig machen, konsistent zu bleiben, und den Punkt zunichte machen, sie überhaupt zu ändern.

Namen, die in Pluralform in Ordnung wären:

• Puffer
• Datenströme
• Drawables
• Standard-Skins
• Mipmaps
• Nbts
• RailPlacements
• Spawnt
• Eingänge
• Modelle
• Texturen
• Dateinamen
• Geschosse
• LookTargets
• Strukturtests
• Tests
• Screenshots
• GlZuweisungen

Namen, die nicht in Ordnung sind, weil sie Massennomen oder kein Substantiv sind:

• Jsons
• Mathe
• Als
• Glfws
• Glättet
• Schäden (der Plural hat eine andere Bedeutung)
• Netzwerke (hier gibt es nur ein Netzwerk)
• NetworkThreads (es gibt nur einen Netzwerk-Thread)
• Netzwerkverschlüsselungen

Namen, die nicht in Ordnung sind, weil sie bereits vergeben sind:

• Verzauberungen
• Karten
• Statuseffekte
• Tränke

Namen, die aus verschiedenen Gründen nicht in Ordnung sind:

• Rotation3s (dieser Name erfordert mehr Nachdenken)
• Chats (obwohl es technisch gesehen der Plural von Chat ist, passt es nicht gut als Utility-Klasse für "den Chat", vorausgesetzt, dafür ist es gedacht. Wenn es sich um Textkomponenten handelt, wäre "Texte" ein guter Name)
• Utils (wir können dies nicht in "s" lol umbenennen, es ist besser als "Util" aufzubewahren)

Insgesamt wären 18/34 Namen als Plural in Ordnung, was bedeutet, dass wir uns bessere Namen für die anderen 16 einfallen lassen müssten. So viel zur Konsistenz.

Ich wäre damit einverstanden, Pluralformen zu verwenden, wo es sinnvoll ist, und auf ein Util-Suffix zurückzugreifen, wo es keinen Sinn ergibt. Dann haben wir zumindest eine Regel, der wir folgen müssen, anstatt zufällig zwischen "Helper" und "Util" zu wählen, was wir derzeit tun.

@Earthcomputer NetworkThreads funktioniert aber gut. Es sind Dienstprogramme für die Arbeit mit Netzwerk-Threads. Es spielt keine Rolle, dass es nur einen von ihnen gibt.

Sie können mir in einem oder zwei dieser Punkte nicht zustimmen, aber das ist nicht der Punkt, es ändert das Gesamtverhältnis von 18/34 nicht sehr.

Ich würde entweder für Util oder Helper argumentieren, sie vollständig zu entfernen macht für mich nicht allzu viel Sinn.

Übrigens, einige können nicht Util genannt werden. Beispielsweise ist DataStreamHelper keine util-Klasse, sondern ein Objekt, das einen Datenstrom umschließt.