社区新闻 LXL插件编写中不使用Format(Text)类的理由

Redbeanw · 2021/09/29

在最近的LXL版本中，LXL新增了Format(Text)类，初衷是为了解决§打字困难和MC颜色代码（数字）难以记忆和辨认的问题。
不可否认的是，此类似乎的确解决了这些问题

但为什么我不建议大家在开发过程中使用该类并且反对该类存在呢？

1 没有必要
首先，MC的样式代码方案的两个问题并非致命，也并非完全不可由个人解决。加载器API提供这个功能是非常累赘的，而且它完全可以让脚本自身实现。
另外，作为一个开发者，可不能这么矫情。

2 无端增加代码体积
拿LXL文档里的例子说：

JavaScript：

mc.broadcast(Format.Red + Format.Bold + "Red & Bold " + Format.DarkGreen + Format.Underline + "DarkGreen & Underline" + Format.Clear + "Clear");

在这里，不理会表达所必要的Format.XX。一共多使用了7个加号，算上缩进多了21个字符。而使用原版MC方案只需这样：

JavaScript：

mc.broadcast("§c§lRed & Bold §2§nDarkGreen & Underline §rClear");

一共长了多少，你自己算吧，如果说此类有利于增加代码可读性，那么无端增加代码体积同样降低代码可读性。

3 无端增加加号使用和API调用，降低性能
RT.
如果你说这对性能影响微乎其微，那么《韩非子》里有句话说：千里之堤，溃于蚁穴。

4 阻碍插件国际化
这是最坏的影响。
LXL的插件如果可以全部支持i18n，那么其对国内外BDS圈影响是不可估量的，在现在，插件国际化可以说是一种必然趋势。
该类如何伤害i18n呢？
我们平常实现插件i18n只需这样：

代码：

-> zh_CN.lang
example.text=§a你有 §1%1§r§a 元

-> 插件.code
sendText(_tr("example.text"),player.money)

你可能已经明白了，这个简单的国际化如果使用Format类实现：

代码：

-> zh_CN.lang
example.text=%1你有 %2%4%3%1 元

-> 插件.code
sendText(_tr("example.text"),Format.Green.Format.DarkBlue,Format.Clear,player.money)

这是很反人类的，而且百害而无一利。如果开发者在开发插件的时候没有考虑国际化，大量使用Format类，后期如果想对插件进行国际化.......

总结与建议
Format类明显弊大于利，如果开发者一开始就走上歪路，后果不堪设想。我在此类刚提供的时候就坚决反对加入此类，无奈最后还是被保留。如果LXL仍不删除此类，那我也没啥办法，只能希望各位开发者尽量避开这玩意了。
这一篇文，是我的个人看法与观点，如果留言讨论，请注意言辞并准备好论据，友善交流。

yqs112358 · 2021/09/30

chuxia · 2021/09/30

虽然我不知道LXL是啥，但是我并不觉得Format类会有你所说的上述问题，而且增长代码体积这完全不是问题，在微弱的性能上面完全不够代码可读性重要。至于国际的话的问题，谁会在语言文件用颜色变量呢~

Redbeanw · 2021/09/30

chuxia 说：
虽然我不知道LXL是啥，但是我并不觉得Format类会有你所说的上述问题，而且增长代码体积这完全不是问题，在微弱的性能上面完全不够代码可读性重要。至于国际的话的问题，谁会在语言文件用颜色变量呢~

1 个人观点不认为此类有助于增加代码可读性，因为读颜色代码本身意义不大，使用Format类反而会让代码难看
2 我说的是“无端增加”，这类不必要的性能损耗完全可以没有
3 为什么不会在语言文件里使用颜色变量？建议多看几个语言文件

chuxia · 2021/09/30

Redbeanw 说：
1 个人观点不认为此类有助于增加代码可读性，因为读颜色代码本身意义不大，使用Format类反而会让代码难看
2 我说的是“无端增加”，这类不必要的性能损耗完全可以没有
3 为什么不会在语言文件里使用颜色变量？建议多看几个语言文件

可读性各有各的看法，比如 §a你有 §1%1§r§a 元这种新手开发者根本看不出这一句话是如何润色的
老手不需要很正常，而且这个也不算强制使用的吧

至于语言文件颜色变量实际上大部分插件都是直接用§1或者&1这种类型，如果真有语言文件用%1你有 %2%4%3%1 元，我很难不怀疑这个开发者或多或少沾点... :evil:

Redbeanw · 2021/09/30

chuxia 说：
可读性各有各的看法，比如 §a你有 §1%1§r§a 元这种新手开发者根本看不出这一句话是如何润色的
老手不需要很正常，而且这个也不算强制使用的吧

至于语言文件颜色变量实际上大部分插件都是直接用§1或者&1这种类型，如果真有语言文件用%1你有 %2%4%3%1 元，我很难不怀疑这个开发者或多或少沾点...

的确没有强制使用啊，标题和结尾很明确：“理由” “建议”
%2%4%3%那种东西当然没人会用，我只是举个例子。

“至于语言文件颜色变量实际上大部分插件都是直接用§1或者&1这种类型”

那么除了语言文件，哪里会用到Format类呢。既然都是§1&2，那这个类可更没存在必要了

chuxia · 2021/09/30

Redbeanw 说：
的确没有强制使用啊，标题和结尾很明确：“理由” “建议”
%2%4%3%那种东西当然没人会用，我只是举个例子。

“至于语言文件颜色变量实际上大部分插件都是直接用§1或者&1这种类型”

那么除了语言文件，哪里会用到Format类呢。既然都是§1&2，那这个类可更没存在必要了

这个类不可能是为语言文件而生的，他最主要的目的就是降低对新手的开发难度以及可读性

Redbeanw · 2021/09/30

chuxia 说：
这个类不可能是为语言文件而生的，他最主要的目的就是降低对新手的开发难度以及可读性

说得好。但这个类最大的问题就是它不是为语言文件而生的。另外，即使他的确降低了新手的开发难度，但这明显将新手导入了歧途，以后插件如果代码量大了且大量使用Format类再想整国际化.......

chuxia · 2021/09/30

Redbeanw 说：
说得好。但这个类最大的问题就是它不是为语言文件而生的。另外，即使他的确降低了新手的开发难度，但这明显将新手导入了歧途，以后插件如果代码量大了如果大量使用Format类再考虑国际化.......

这倒不会，新手在开发有一定水平之后，代码多就会让他很烦躁（常见表现砸键盘），他就会自发性的寻找减少代码量的方法。

Redbeanw · 2021/09/30

chuxia 说：
这倒不会，新手在开发有一定水平之后，代码多就会让他很烦躁（常见表现砸键盘），他就会自发性的寻找减少代码量的方法。

保护键盘人人有责，最好的办法就是一开始就不使用而不是先污染后治理。我也不觉得Format类不存在新手们就会放弃开发插件

chuxia · 2021/09/30

Redbeanw 说：
保护键盘人人有责，最好的办法就是一开始就不使用而不是先污染后治理。我也不觉得Format类不存在新手们就会放弃开发插件

我觉得你没怎么用过常量，建议了解下，像这种Format类常量是很常见

Redbeanw · 2021/09/30

chuxia 说：
我觉得你没怎么用过常量，建议了解下，像这种Format类常量是很常见

不要作不当的类比，这和常量不常量没关系。如果在LXL中Format类弊大于利，那么它就不应被使用也不应该存在

chuxia · 2021/09/30

Redbeanw 说：
不要作不当的类比，这和常量不常量没关系。如果在LXL中Format类弊大于利，那么它就不应被使用也不应该存在

这不是类比，这东西就是常量....

Redbeanw · 2021/09/30

chuxia 说：
这不是类比，这东西就是常量....

我说的类比是你将其他地方可能有用的常量和LXL的Format类常量作了类比，不是吗？

chuxia · 2021/09/30

Redbeanw 说：
我说的类比是你将其他地方可能有用的常量和LXL的Format类常量作了类比，不是吗？

像这种固定值作为常量不是很常见？基本上每个语言的颜色都是常量，而不是让开发者输入§1

Redbeanw · 2021/09/30

chuxia 说：
像这种固定值作为常量不是很常见？基本上每个语言的颜色都是常量，而不是让开发者输入§1

我没有否定这很常见啊，但不能因为常见就盲目跟风不是（尽管LXL开发者可能没有跟风这个想法）？它有明显的问题，它不应被使用不应该存在，我刚刚就已经讲的很明确了。

chuxia · 2021/09/30

Redbeanw 说：
我没有否定这很常见啊，但不能因为常见就盲目跟风不是（尽管LXL开发者可能没有跟风这个想法）？它有明显的问题，它不应被使用不应该存在，我刚刚就已经讲的很明确了。

你的想法就是该类的频繁使用会增加代码量和性能损害，然而实际上常量的性能不应该会比你那种写法低，为什么呢，因为常量在初始化之后就已经在内存分配了地址，之后用到直接去地址取值，而你的那种写法每次用到那一串颜色变量都是会从内存新开一片空间存放。虽然用完都会回收。也就是不会有你所谓的明显问题

Redbeanw · 2021/09/30

chuxia 说：
你的想法就是该类的频繁使用会增加代码量和性能损害，然而实际上常量的性能不应该会比你那种写法低，为什么呢，因为常量在初始化之后就已经在内存分配了地址，之后用到直接去地址取值，而你的那种写法每次用到那一串颜色变量都是会从内存新开一片空间存放。虽然用完都会回收。也就是不会有你所谓的明显问题

忘了你没用过LXL，你还是去看看LXL的实现再说吧，其实这个Format类的实现是普通的类（当接口调用）并不是什么常量。我在之前没反驳你的原因是这在广义上和常量的定义有点像。
再说，照你这么说用Format类反而比我直接用MC写法还慢？你不会真是这样认为的吧？

Lition · 2021/10/01

EL 表达式

JavaScript：

mc.broadcast(`${Format.Red}${Format.Bold}Red & Bold ${Format.DarkGreen}${Format.Underline}DarkGreen & Underline${Format.Clear}Clear`);

Redbeanw · 2021/10/01

Lition 说：

是可以这么搞，但没有解决问题啊。Lua没有这种写法吧？1 2 3 问题还是存在

社区新闻 LXL插件编写中不使用Format(Text)类的理由

相似主题

主题

资源

回复

在线管理成员

在线会员

我们重视您的隐私