Yarn: Prefixos vs sufixos na nomenclatura de classes

Criado em 29 out. 2018  ·  17Comentários  ·  Fonte: FabricMC/yarn

"BiomeDesert" vs "DesertBiome", etc. Ou "ComponentTranslatable" vs "TranslatableComponent".

O primeiro tem vantagens ao classificar nomes em um editor e é minha preferência pessoal; o último é mais comum no desenvolvimento Java e é preferido pela maioria das outras pessoas.

discussion

Comentários muito úteis

sim. Já estou interessado em fazer isso, é apenas uma quantidade decente de esforço sentar e fazer isso.

Todos 17 comentários

de uma discussão privada com @asiekierka outro dia:

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

Eu diria que a pesquisa na maioria dos IDEs Java modernos seria confusa o suficiente para que, independentemente da ordem de BlockBed / BedBlock, o resultado fosse mostrado.

Acho que Mojang usa sufixos (BedBlock) ou apenas nomes (Bed).

[recorte!]

Essas classes estão, provavelmente, no mesmo pacote e são nomeadas como:

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

Outro exemplo, que também mostra que os nomes Mojang não têm I prefixos para interfaces:

[recorte!]

O primeiro tem vantagens ao classificar nomes em um editor

Isso é verdade se tudo for mapeado em um grande pacote "coletor" (por exemplo, net.minecraft.src ), mas não é um bom substituto para o mapeamento correto dos pacotes. E se as classes são colocadas em pacotes como blocks , items , entities , os prefixos tornam-se redundantes.

Embora seus esforços sejam louváveis, não poste conteúdo MCP aqui. Use mapeamentos Enigma ou mapeamentos Tiny do pomf para demonstrar seu ponto da próxima vez, ou sugira sem postar nomes diretamente.

A pesquisa é apreciada, no entanto! Já sabíamos que Mojang não usava prefixos I graças ao Brigadeiro, mas a outra dica é bem interessante. Eu estava planejando olhar para a ordem alfabética sozinho em algum ponto, no entanto, também não é necessário presumir que os "nomes internos" do Minecraft são perfeitos ou adequados para um ambiente de desenvolvimento mais modificado.

Eu pessoalmente gosto de ter os prefixos, porque isso significa que todos os itens são agrupados, todos os biomas são agrupados etc. Claro, o contra-argumento é que os sufixos fazem tudo o que tem algo em comum ser agrupado, como IronIngot, IronSword, IronBlock, IronChestplate, etc.

@Boundarybreaker Na verdade, é que eles estão em pacotes de qualquer maneira. Então, em .block, as coisas já estão agrupadas. Não importa se é BlockBed e BlockChest ou BedBlock e ChestBlock.

Ah sim. Essa é uma boa opinião. Eu estava pensando mais do lado do mod-dev. Estou bem com sufixos, então.

Pessoalmente, em todo o meu código, uso prefixos em vez de sufixos nos nomes das minhas classes. Existem algumas exceções a essa regra para praticamente todas as situações que surgem, acabo optando por prefixos.

Acho que funciona melhor ao pesquisar um tipo de objeto em meu IDE e, honestamente, parece melhor para mim.

Muito disso é baseado em opinião e se você olhar o código-fonte de outros mods no github, fica bem claro que a maioria das pessoas fica feliz com nomes de classes usando um prefixo em vez de um sufixo.

Acho que todos os mods usam prefixação porque estão usando nomes MCP e os nomes MCP usam principalmente prefixação porque há muito tempo todo o minecraft foi desofuscado em um único pacote net.minecraft.src . No entanto, especialmente em novos códigos, há muitos exemplos de sufixos. Por exemplo, ILightEngine , ChunkTask , SurfaceBuilder , IWorldCarver , IChunkGenSettings implementações, Config / Pieces / Structure classes para estruturas. O código para receitas e gerações de loot tem muitas classes derivadas que não incluem o nome da classe base.

✓ CONSIDERE terminar o nome das classes derivadas com o nome da classe base.

Isso é muito legível e explica a relação claramente. Alguns exemplos disso no código são: ArgumentOutOfRangeException, que é um tipo de Exception, e SerializableAttribute, que é um tipo de Attribute. No entanto, é importante usar o bom senso ao aplicar esta diretriz; por exemplo, a classe Button é um tipo de evento Control, embora Control não apareça em seu nome.

Das Diretrizes de Design C #

Acho que usar prefixos meio que bloqueia você nesse esquema e não permite qualquer "julgamento". Mas talvez não seja realmente necessário para hierarquias de herança ampla, como a de Block ou Item

Acabei de pensar, veja as implementações JEI. Não há precedentes de prefixação na api e, portanto, todas as classes de suporte JEI da comunidade de modding são Máquina + Categoria / Wrapper / etc.

O MCP não teve o sufixo movido por causa das dependências em grande escala dos mods existentes. Este não é o caso do tecido.

sim. Já estou interessado em fazer isso, é apenas uma quantidade decente de esforço sentar e fazer isso.

Eu acabei de pensar: prefixos! = Grafia invertida, eles também vêm em sabores diferentes

Exemplos do MCP: [recorte!]

Acho que você concordará que a inconsistência na nomenclatura é ruim, nomes como [recorte!] São terríveis.

Provavelmente estou muito atrasado com isso ...

Pare de postar exemplos de MCP nos canais de comunicação pomf ou serei forçado a bloquear você no repositório GitHub.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

Bixilon picture Bixilon  ·  5Comentários

altrisi picture altrisi  ·  4Comentários

asiekierka picture asiekierka  ·  3Comentários

ChloeDawn picture ChloeDawn  ·  6Comentários

quat1024 picture quat1024  ·  3Comentários