Yarn: Präfixe vs. Suffixe bei der Klassenbenennung

aus einer privaten Diskussion mit @asiekierka neulich :

22:34 <kasheek> I have a 'block' package with:
22:34 <kasheek> 'BedBlock'
22:34 <kasheek> 'CactusBlock'
22:34 <kasheek> 'MagmaBlock'
22:34 <kasheek> and I import them all into one of my classes. I can:
22:34 <kasheek> - look at the imports, in alphabetical order, without reading "Block" before each word
22:34 <kasheek> - search for ".BedBlock" and get results for BedBlock *and* BedBlockEntity *and* BedBlockEntityRenderer
22:34 <asie> that last one
22:34 <asie> that's a good argument

Ich würde argumentieren, dass die Suche in den meisten modernen Java-IDEs so verschwommen wäre, dass das Ergebnis unabhängig von der Reihenfolge von BlockBed/BedBlock angezeigt würde.

Ich denke, Mojang verwendet entweder Suffixe (BedBlock) oder nur Namen (Bed).

[schnipsen!]

Diese Klassen befinden sich wahrscheinlich im selben Paket und werden wie folgt benannt:

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

Ein weiteres Beispiel, das auch Mojang-Namen zeigt, hat keine I Präfixe für Schnittstellen:

[schnipsen!]

Ersteres hat Vorteile beim Sortieren von Namen in einem Editor

Dies ist wahr, wenn alles in einem großen "Senken"-Paket abgebildet wird (zB net.minecraft.src ), aber es ist ein schlechter Ersatz für das korrekte Zuordnen von Paketen. Und wenn Klassen in Pakete wie blocks , items , entities gepackt werden, werden Präfixe überflüssig.

Auch wenn Ihre Bemühungen lobenswert sind, posten Sie hier bitte keine MCP-Inhalte. Bitte verwenden Sie Enigma-Mappings oder Tiny-Mappings von pomf, um Ihren Standpunkt beim nächsten Mal zu demonstrieren, oder weisen Sie darauf hin, ohne Namen direkt zu posten.

Die Forschung wird jedoch geschätzt! Wir wussten bereits, dass Mojang dank Brigadier keine I-Präfixe verwendet, aber der andere Hinweis ist ziemlich interessant. Ich hatte mir irgendwann vorgenommen, mir die alphabetische Sortierung selbst anzuschauen, aber es muss auch nicht davon ausgegangen werden, dass die "internen Namen" von Minecraft perfekt oder passend für eine eher modifizierte Entwicklungsumgebung sind.

Ich persönlich mag es, die Präfixe zu haben, weil das bedeutet, dass alle Elemente gruppiert werden, alle Biome gruppiert werden usw. Das Gegenargument ist natürlich, dass Suffixe dazu führen, dass alles, was etwas gemeinsam hat, gruppiert wird, wie IronIngot, IronSword, IronBlock, IronChestplate usw.

@Boundarybreaker Eigentlich sind sie sowieso in Paketen. In .block sind die Dinge also bereits gruppiert. Egal ob BlockBed und BlockChest oder BedBlock und ChestBlock.

Oh ja. Das ist ein guter Punkt. Ich dachte eher von der Mod-Dev-Seite. Mit Suffixen komme ich gut klar.

Persönlich verwende ich in meinem gesamten Code Präfixe anstelle von Suffixen für meine Klassennamen. Es gibt einige Ausnahmen von dieser Regel für so ziemlich jede Situation, die auftritt, wenn ich am Ende nach Präfixen suche.

Ich finde, es funktioniert besser, wenn ich in meiner IDE nach einem Objekttyp suche, und sieht für mich ehrlich gesagt einfach besser aus.

Vieles davon ist meinungsbasiert und wenn man sich den Quellcode anderer Mods auf github ansieht, ist es ziemlich klar, dass die meisten Leute mit Klassennamen zufrieden sind, die ein Präfix anstelle eines Suffixes verwenden.

Ich denke, alle Mods verwenden Präfixe, weil sie MCP-Namen verwenden, und MCP-Namen verwenden meistens Präfixe, weil vor langer Zeit alle Minecraft in ein einzelnes net.minecraft.src Paket enthüllt wurde. Vor allem in neuen Code-Features gibt es jedoch viele Beispiele mit Suffixen. ZB ILightEngine , ChunkTask , SurfaceBuilder , IWorldCarver , IChunkGenSettings Implementierungen, Config/Pieces/Structure Klassen für Strukturen. Code für Rezepte und Beutegenerationen enthält viele abgeleitete Klassen, die den Namen der Basisklasse nicht enthalten.

✓ BETRACHTEN SIE, den Namen der abgeleiteten Klassen mit dem Namen der Basisklasse zu enden.

Dies ist sehr gut lesbar und erklärt den Zusammenhang anschaulich. Einige Beispiele dafür im Code sind: ArgumentOutOfRangeException, eine Art Exception, und SerializableAttribute, eine Art Attribut. Es ist jedoch wichtig, bei der Anwendung dieser Leitlinie vernünftiges Urteilsvermögen zu fällen; Die Button-Klasse ist beispielsweise eine Art Control-Ereignis, obwohl Control nicht in ihrem Namen vorkommt.

Aus den C#-Designrichtlinien

Ich denke, die Verwendung von Präfixen sperrt Sie in diesem Schema und lässt kein "Urteil" zu. Aber vielleicht wird es für breite Vererbungshierarchien wie die von Block oder Item nicht wirklich benötigt

Ich habe mir gerade überlegt, schau dir JEI-Implementierungen an. Es gibt keine Präfixe in der API und daher sind alle JEI-Unterstützungsklassen der Modding-Community Machine+Category/Wrapper/etc.

MCP hatte das Suffix verschieben wegen der großen Abhängigkeiten von bestehenden Mods nicht. Bei Stoffen ist dies nicht der Fall.

Jawohl. Ich habe schon Lust darauf, es ist nur eine anständige Anstrengung, sich hinzusetzen und es zu tun .

Ich habe mir gerade gedacht: Präfixe != Rückwärtsschreibweise, außerdem gibt es sie in verschiedenen Geschmacksrichtungen

Beispiele aus MCP: [schnipsen!]

Ich denke, Sie werden mir zustimmen, dass Inkonsistenzen bei der Namensgebung schlecht sind, Namen wie [schnipsen!] sind schrecklich.

Damit bin ich wohl zu spät...

Bitte hören Sie auf, MCP-Beispiele auf pomf-Kommunikationskanälen zu veröffentlichen, oder ich bin gezwungen, Sie vom GitHub-Repository zu blockieren.

https://github.com/FabricMC/pomf/tree/18w47b