有 12 个以Helper
后缀的类:
net/minecraft/server/rcon/BufferHelper
net/minecraft/server/rcon/DataStreamHelper
net/minecraft/client/gui/DrawableHelper
net/minecraft/client/util/math/Rotation3Helper
net/minecraft/client/util/DefaultSkinHelper
net/minecraft/client/texture/MipmapHelper
net/minecraft/nbt/NbtHelper
net/minecraft/block/RailPlacementHelper
net/minecraft/world/SpawnHelper
net/minecraft/util/JsonHelper
net/minecraft/util/math/MathHelper
net/minecraft/enchantment/EnchantmentHelper
有 17 个以Util
后缀的类:
net/minecraft/client/sound/AlUtil
net/minecraft/client/util/InputUtil
net/minecraft/client/util/GlfwUtil
net/minecraft/client/util/SmoothUtil
net/minecraft/client/model/ModelUtil
net/minecraft/client/texture/TextureUtil
net/minecraft/util/ChatUtil
net/minecraft/util/MapUtil
net/minecraft/util/FileNameUtil
net/minecraft/util/Util
net/minecraft/entity/ProjectileUtil
net/minecraft/entity/ai/brain/task/LookTargetUtil
net/minecraft/entity/effect/StatusEffectUtil
net/minecraft/entity/DamageUtil
net/minecraft/potion/PotionUtil
net/minecraft/test/StructureTestUtil
net/minecraft/test/TestUtil
有 5 个以Utils
后缀的类:
net/minecraft/client/util/ScreenshotUtils
net/minecraft/client/util/NetworkUtils
net/minecraft/client/util/GlAllocationUtils
net/minecraft/network/NetworkThreadUtils
net/minecraft/network/NetworkEncryptionUtils
我们可能应该选择一个标准并坚持下去。 我个人赞成Utils,但我想听听其他人的意见。
我最喜欢单数Util
。 👍 为实用程序。 👎 用于 Helper,😕 用于 Utils
tbh 我可以采取任何方式,只是让我们保持一致。
此外,如果我们有动词,我们可以使用 -ing(动名词),例如Chatting
NetworkThreading
或复数名词,例如Projectiles
Screenshots
over Helper
Util
等。
这使得诸如MathHelper
-> Maths
之类的事情变得困难? 或者Util
-> s
??
我很久以前就为Maths
争论过,因为它是Mathematics
的有效缩写。 https://github.com/FabricMC/yarn/issues/249#issuecomment -446102638
Yarn 使用美国英语名称,其中Maths
不是Mathematics
的有效缩写。
在这种既不适用动名词也不适用复数的情况下,我建议回退到Helper
后缀。 否则更喜欢ing
或s
,例如Texts
另外DrawableHelper
不是实用程序类,而是具有许多方便实例方法的功能接口或抽象类
我对 liach 的 -ing 和 -s 提议的问题是,它很难使任何事情保持一致,完全违背了问题的目的。 你可以让它如此计数名词实用程序类以-s
结尾,但是你会有例外: Nbts
, RailPlacements
, Maps
? 要做到一致是不可能的。
我们应该采用一个标准并坚持下去。 查看投票,应该是Helper
或Util
,而不是Utils
。
Util
优于Helper
的一个论点是,将Util
类本身称为Helper
是没有意义的。 我认为MathHelper
被称为MathUtil
不会那么糟糕,只是每个人都习惯了它被称为MathHelper
。 我曾在数学实用程序类被称为MathUtil
的项目中工作过,它绝对没问题,没有任何区别。 MathUtil
这个名字甚至没有在MathHelper
重命名问题中讨论过。
目前有比Helper
类更多的Util
类,但这需要根据这些类的实际使用频率来衡量,所以我现在要研究一下并报告结果.
看来大部分人都是为了Helper
这个后缀。 因此,我建议将当前所有以Util
或Utils
结尾的类(除了Util
本身)重命名为以Helper
结尾。 其他类以Helper
结尾的重命名可以在单独的问题中讨论。
看来大部分人都是为了
Helper
这个后缀。
不?
哦,哎呀,我一定是瞎了。 然后我建议我们将所有以Helper
结尾的类重命名为以Util
结尾。
我建议后缀是魔鬼的作品,我们将所有以*elperer
和*til
结尾的类重命名为没有该后缀。
MathHelper
-> Maths
。
PiglinHelper
-> Piglins
Yarn 使用美国英语名称,其中
Maths
不是Mathematics
的有效缩写。
我以为Maths
是一个专门的美国术语?
MathHelper
-> Mathinator
Maps
? 一世
另请注意,番石榴(我认为是番石榴?)使用复数模式: Maps
、 Sets
、 Collections
、 Streams
。
这是我使用复数的问题。 虽然名字看起来不错,但也有太多的例外。 要么是因为这个词是一个大众名词(例如“math”),因此没有复数,要么是因为复数已经被另一个图书馆采用(例如“map”)。 这将使保持一致变得太难了,首先就失去了改变它们的意义。
可以以复数形式出现的名字:
由于是大众名词或不是名词而不合适的名称:
因已被占用而无法使用的名称:
因各种原因不适合的名称:
总的来说,18/34 个名字可以作为复数形式,这意味着我们必须为其他 16 个名字想出更好的名字。为了保持一致性。
我可以在有意义的地方使用复数,在没有意义的地方使用 Util 后缀。 那么至少我们有一个规则要遵循,而不是在“Helper”和“Util”之间随机选择,这是我们目前所做的。
不过, @Earthcomputer NetworkThreads
工作正常。 它是用于处理网络线程的实用程序。 没关系,只有其中一个。
你可能会在其中的一两点上不同意我的观点,但这不是重点,它不会改变 18/34 的整体比例。
我会争论Util
或Helper
,完全删除它们对我来说没有太大意义。
顺便说一句,有些不能命名为Util
。 例如, DataStreamHelper
不是 util 类,它是包装数据流的对象。
最有用的评论
我最喜欢单数
Util
。 👍 为实用程序。 👎 用于 Helper,😕 用于 Utils