Yarn: 类命名中的前缀与后缀

来自前几天与

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

我认为大多数现代 Java IDE 中的搜索都足够模糊，以至于无论 BlockBed/BedBlock 的顺序如何，结果都会显示。

我认为 Mojang 使用后缀 (BedBlock) 或仅使用名称 (Bed)。

[剪！]

这些类可能在同一个包中，并且命名如下：

RenderType
RepeaterBlock
RotatedPillarBlock
Rotation
SandBlock

另一个例子，它也显示 Mojang 名称没有接口的I前缀：

[剪！]

前者在编辑器中排序名称时具有优势

如果一切都被映射到一个大的“接收器”包（例如net.minecraft.src ）中，这是真的，但它是正确映射包的糟糕替代品。 如果类被放在像blocks 、 items 、 entities ，前缀就会变得多余。

虽然您的努力值得称道，但请不要在此处发布 MCP 内容。 下次请使用 pomf 中的 Enigma 映射或 Tiny 映射来证明您的观点，或者在不直接发布名称的情况下暗示它。

然而，这项研究值得赞赏！ 由于 Brigadier，我们已经知道 Mojang 不使用 I 前缀，但另一个提示非常有趣。 我打算在某个时候自己查看字母顺序，但是也不需要假设 Minecraft 的“内部名称”是完美的或适合更修改的开发环境。

我个人喜欢使用前缀，因为这意味着所有项目都组合在一起，所有生物群系都组合在一起，等等。当然，相反的论点是后缀使所有具有共同点的东西都组合在一起，例如 IronIngot， IronSword、IronBlock、IronChestplate 等

@Boundarybreaker实际上，无论如何它们都在包装中。 因此，在 .block 中，事物已经组合在一起。 是 BlockBed 和 BlockChest 还是 BedBlock 和 ChestBlock 都没有关系。

啊，是的。 这是一个好点。 我更多的是从 mod-dev 方面思考。 那么我可以使用后缀。

就我个人而言，在我的所有代码中，我在类名上使用前缀而不是后缀。 对于几乎所有出现的情况，该规则都有一些例外，我最终会使用前缀。

我发现它在我的 IDE 中搜索某种类型的对象时效果更好，老实说，对我来说看起来更好。

其中很多是基于意见的，如果您查看 github 上的其他 mods 源代码，很明显大多数人对使用前缀而不是后缀的类名感到满意。

我认为所有 mod 都使用前缀，因为它们使用 MCP 名称，而 MCP 名称大多使用前缀，因为很久以前所有的 minecraft 都被反混淆为单个net.minecraft.src包。 然而，特别是在新代码中，特性有很多带有后缀的示例。 例如ILightEngine 、 ChunkTask 、 SurfaceBuilder 、 IWorldCarver 、 IChunkGenSettings实现、结构的 Config/Pieces/Structure 类。 配方和战利品代的代码有许多不包含基类名称的派生类。

✓ 考虑以基类的名称结束派生类的名称。

这非常具有可读性，并且清楚地解释了这种关系。 代码中的一些示例是：ArgumentOutOfRangeException，它是一种异常，和 SerializableAttribute，它是一种属性。 然而，在应用本指南时使用合理的判断是很重要的； 例如，Button 类是一种 Control 事件，尽管 Control 没有出现在其名称中。

来自C# 设计指南

我认为在该方案中使用前缀可以锁定您，并且不允许进行任何“判断”。 但对于广泛的继承层次结构，例如Block或Item继承层次结构，它可能并不是真正需要的

我只是想，看看 JEI 的实现。 api 中没有前缀先例，因此所有修改社区 JEI 支持类都是机器+类别/包装器/等。

由于现有模组的大规模依赖，MCP 没有后缀移动。 这在面料中并非如此。

是的。 我已经很想这样做了，坐下来做这件事需要付出相当多的努力。

我只是想：前缀！= 向后拼写，它们也有不同的风格

来自 MCP 的例子：[snip!]

我想你会同意命名不一致是不好的，像 [snip!] 这样的名字很糟糕。

我可能为时已晚...

请停止在 pomf 通信渠道上发布 MCP 示例，否则我将被迫阻止您访问 GitHub 存储库。

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