Yarn: Préfixes vs suffixes dans la dénomination des classes

de la discussion privée avec @asiekierka l'autre jour :

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

Je dirais que la recherche dans la plupart des IDE Java modernes serait suffisamment floue pour que le résultat s'affiche, quel que soit l'ordre de BlockBed/BedBlock.

Je pense que Mojang utilise soit des suffixes (BedBlock) soit juste des noms (Bed).

[couper!]

Ces classes sont, probablement, dans le même package et sont nommées comme :

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

Un autre exemple, qui montre également que les noms Mojang n'ont pas I préfixes

[couper!]

Le premier présente des avantages lors du tri des noms dans un éditeur

C'est vrai si tout est mappé dans un gros paquet "récepteur" (par exemple net.minecraft.src ), mais c'est un mauvais substitut pour mapper correctement les paquets. Et si les classes sont placées dans des packages comme blocks , items , entities , les préfixes deviennent redondants.

Bien que vos efforts soient louables, veuillez ne pas publier de contenu MCP ici. Veuillez utiliser les mappages Enigma ou les mappages Tiny de pomf pour démontrer votre point de vue la prochaine fois, ou le suggérer sans publier de noms directement.

La recherche est appréciée, cependant! Nous savions déjà que Mojang n'utilisait pas les préfixes I grâce à Brigadier, mais l'autre indice est assez intéressant. J'avais l'intention de regarder moi-même l'ordre alphabétique à un moment donné, mais il ne faut pas non plus supposer que les "noms internes" de Minecraft sont parfaits ou adaptés à un environnement de développement plus modifié.

Personnellement, j'aime avoir les préfixes, car cela signifie que tous les éléments sont regroupés, tous les biomes sont regroupés, etc. Bien sûr, le contre-argument est que les suffixes regroupent tout ce qui a quelque chose en commun, comme IronIngot, IronSword, IronBlock, IronChestplate, etc.

@Boundarybreaker En fait, c'est de toute façon qu'ils sont dans des paquets. Donc, dans .block, les choses sont déjà regroupées. Peu importe que ce soit BlockBed et BlockChest ou BedBlock et ChestBlock.

Ah ouais. C'est un bon point. Je pensais plus du côté mod-dev. Je suis d'accord avec les suffixes, alors.

Personnellement, dans tout mon code, j'utilise des préfixes au lieu de suffixes sur mes noms de classe. Il y a quelques exceptions à cette règle pour à peu près toutes les situations qui se présentent, je finis par choisir des préfixes.

Je trouve que cela fonctionne mieux lors de la recherche d'un type d'objet dans mon IDE, et honnêtement, cela me semble mieux.

Une grande partie de cela est basée sur des opinions et si vous regardez le code source d'autres mods sur github, il est assez clair que la plupart des gens sont satisfaits des noms de classe utilisant un préfixe au lieu d'un suffixe.

Je pense que tous les mods utilisent le préfixe car ils utilisent des noms MCP et les noms MCP utilisent principalement le préfixe car il y a longtemps, tout minecraft était désobscurci en un seul paquet net.minecraft.src . Cependant, en particulier dans le nouveau code, les fonctionnalités, il y a beaucoup d'exemples avec des suffixes. Par exemple, ILightEngine , ChunkTask , SurfaceBuilder , IWorldCarver , IChunkGenSettings implémentations, Config/Pieces/Structure classes pour les structures. Le code pour les recettes et les générations de butin a de nombreuses classes dérivées qui n'incluent pas le nom de la classe de base.

✓ ENVISAGEZ de terminer le nom des classes dérivées par le nom de la classe de base.

Ceci est très lisible et explique clairement la relation. Voici quelques exemples dans le code : ArgumentOutOfRangeException, qui est une sorte d'exception, et SerializableAttribute, qui est une sorte d'attribut. Cependant, il est important de faire preuve de discernement dans l'application de cette directive ; par exemple, la classe Button est une sorte d'événement Control, bien que Control n'apparaisse pas dans son nom.

À partir des directives de conception C#

Je pense que l'utilisation de préfixes vous bloque en quelque sorte dans ce schéma et ne permet aucun "jugement". Mais peut-être que ce n'est pas vraiment nécessaire pour les hiérarchies d'héritage larges, comme celle de Block ou Item

Je viens de penser, regardez les implémentations JEI. Il n'y a pas de précédents de préfixe dans l'api et donc toutes les classes de support JEI de la communauté de modding sont Machine+Category/Wrapper/etc.

MCP n'avait pas le suffixe déplacé en raison de dépendances à grande échelle des mods existants. Ce n'est pas le cas du tissu.

Oui. J'ai déjà envie de le faire, c'est juste un effort décent pour s'asseoir et le faire .

Je viens de penser : préfixes != épellation à l'envers, ils existent aussi en différentes saveurs

Exemples de MCP : [coupez !]

Je pense que vous conviendrez que l'incohérence dans les noms est mauvaise, les noms comme [couper!] sont terribles.

J'arrive probablement trop tard avec ça...

Veuillez arrêter de publier des exemples de MCP sur les canaux de communication pomf, ou je serai obligé de vous bloquer à partir du référentiel GitHub.

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