Yarn: Prefijos vs sufijos en la nomenclatura de clases

de la discusión privada con @asiekierka el otro día:

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

Yo diría que la búsqueda en la mayoría de los IDE de Java modernos sería lo suficientemente borrosa como para que, independientemente del pedido de BlockBed / BedBlock, se mostrara el resultado.

Creo que Mojang usa sufijos (BedBlock) o solo nombres (Bed).

[¡recorte!]

Esas clases están, probablemente, en el mismo paquete y se denominan así:

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

Otro ejemplo, que también muestra que los nombres de Mojang no tienen prefijos I para interfaces:

[¡recorte!]

El primero tiene ventajas al ordenar nombres en un editor.

Esto es cierto si todo se mapea en un gran paquete "sumidero" (por ejemplo, net.minecraft.src ), pero es un mal sustituto para mapear paquetes correctamente. Y si las clases se colocan en paquetes como blocks , items , entities , los prefijos se vuelven redundantes.

Si bien sus esfuerzos son encomiables, no publique contenido de MCP aquí. Utilice las asignaciones de Enigma o las asignaciones Tiny de pomf para demostrar su punto la próxima vez, o insinúelo sin publicar nombres directamente.

Sin embargo, se agradece la investigación. Ya sabíamos que Mojang no usaba prefijos I gracias a Brigadier, pero la otra pista es bastante interesante. Estaba planeando mirar el orden alfabético en algún momento, sin embargo, tampoco es necesario asumir que los "nombres internos" de Minecraft son perfectos o adecuados para un entorno de desarrollo más modificado.

Personalmente, me gusta tener los prefijos, porque eso significa que todos los elementos se agrupan, todos los biomas se agrupan, etc. Por supuesto, el contraargumento es que los sufijos hacen que todo lo que tiene algo en común se agrupe, como IronIngot, IronSword, IronBlock, IronChestplate, etc.

@Boundarybreaker En realidad, de todos modos están en paquetes. Entonces, en .block, las cosas ya están agrupadas. No importa si es BlockBed y BlockChest o BedBlock y ChestBlock.

Ah sí. Ese es un buen punto. Estaba pensando más desde el lado de mod-dev. Entonces estoy bien con los sufijos.

Personalmente, en todo mi código utilizo prefijos en lugar de sufijos en los nombres de mis clases. Hay algunas excepciones a esa regla para casi todas las situaciones que surgen y termino optando por prefijos.

Me parece que funciona mejor cuando busco un tipo de objeto en mi IDE y, sinceramente, me parece mejor.

Mucho de esto se basa en opiniones y si miras el código fuente de otros mods en github, es bastante claro que la mayoría de las personas están contentas con los nombres de clases que usan un prefijo en lugar de un sufijo.

Creo que todos los mods usan prefijos porque usan nombres MCP y los nombres MCP usan principalmente prefijos porque hace mucho tiempo todo Minecraft se desofuscó en un solo paquete net.minecraft.src . Sin embargo, espacialmente en el nuevo código, hay muchos ejemplos que van con sufijos. Ej. ILightEngine , ChunkTask , SurfaceBuilder , IWorldCarver , IChunkGenSettings implementaciones, clases Config / Piezas / Estructura para estructuras. El código para recetas y generaciones de botines tiene muchas clases derivadas que no incluyen el nombre de la clase base.

✓ CONSIDERE terminar el nombre de las clases derivadas con el nombre de la clase base.

Esto es muy legible y explica la relación con claridad. Algunos ejemplos de esto en el código son: ArgumentOutOfRangeException, que es una especie de Excepción, y SerializableAttribute, que es una especie de Atributo. Sin embargo, es importante usar un juicio razonable al aplicar esta guía; por ejemplo, la clase Button es una especie de evento Control, aunque Control no aparece en su nombre.

De las pautas de diseño de C #

Creo que el uso de prefijos te bloquea en ese esquema y no permite ningún "juicio". Pero tal vez no sea realmente necesario para jerarquías de herencia amplias, como la de Block o Item

Solo pensé, mira las implementaciones de JEI. No hay precedentes de prefijos en api, por lo que en todas las clases de soporte de JEI de la comunidad de modding son Machine + Category / Wrapper / etc.

MCP no tenía el sufijo mover debido a las dependencias a gran escala de los mods existentes. Este no es el caso de la tela.

Si. Ya estoy interesado en hacerlo, es solo una cantidad decente de esfuerzo para sentarme y hacerlo .

Acabo de pensar: prefijos! = Ortografía al revés, también vienen en diferentes sabores

Ejemplos de MCP: [snip!]

Creo que estará de acuerdo en que la incoherencia en los nombres es mala, los nombres como [snip!] Son terribles.

Probablemente sea demasiado tarde con esto ...

Deje de publicar ejemplos de MCP en los canales de comunicación pomf o me veré obligado a bloquearlo del repositorio de GitHub.

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