关于类及方法的命名，三方工具库的使用

[scruel]

这个库感觉对代码洁癖患者有点不友好。
比如字符串工具类的命名上，Apache Commons 的命名是 StringUtils，而这个工具类是 StrUtil
而且看了源代码，也发现有些工具方法的实现没有其他库的效率高（可能是作者坚持不使用 Cglib 等三方库的问题，当然依赖少也是一大特色）。
参与协作过程中也发现作者的基础并不扎实，并且经常会按习惯乱关闭 PR，这点个人很不能接受。
所以一方面想问问这个库的命名有所谓意义上的规范吗，还是随心来定的。
以及 hutool-bom 不遵从业界 bom 约定，而是自行整了一套所谓的“排除模式”等等。
另一方面，现在有很多的开源三方库，各位会在项目中导入多个三方库吗？
还是自己利用三方库的源码再封一套自己公司或项目的工具类？免得遇到各种判断的不一致问题。

以字符串处理类举个例子：

1. 判断字符串是否为空：

apache.commons.StringUtils.isEmpty(" ")       = false
hutool.StrUtil.isEmpty(" ")       = true

2. 去除字符串中的空字符方法，几个工具类的具体实现也是有区别的，最终会去掉的字符也不一样。

[wangliang181230]

我也很不习惯后面少个s，单词不写完整的。

[looly]

这个和开发者的习惯有关系。

Util vs Utils

关于工具类的定义，有XXXUtils、XXXUtil、XXXTools、XXXKit，XXXs，各种各种。

JDK和Guava的命名风格是XXXs，例如Files等，apache-commons倾向于XXXUtils。

Hutool的理解是：XXXUtil中Util是个工具体，是不可数的，StrUtil就是String相关的工具体，如果使用StringUtils，就是理解成String的各种工具方法大集合，都没有错误，纯粹是风格问题。

简写问题

Str这个词并非Hutool创造的，如果你熟悉Python，会发现有个函数就叫str()（见：https://www.w3school.com.cn/python/ref_func_str.asp ），因此Hutool将这种个人认为较为好识别的简化保留了下来。

这种借鉴类的简写大量的在Hutool中使用，例如很多方法借鉴了Linux的Shell命令，如：FileUtil.ls，这样即保证了可识别性，又做到了较好的友好性。

效率问题

暂时知道效率不高的工具类是BeanUtil.copyProperties，使用反射因此性能一般（没法和cglib比，但是比apache-commons好），如果你发现了其他效率比较低的工具类，欢迎提issue或pr优化。

第三方库的使用

个人理解是根据业务不同，在通用库的基础上封装业务相关的工具不可避免，如加入业务对象、业务流程控制等，看具体业务场景了。

[scruel]

@looly 增加对 hutool-bom 的提问。#1561 #1261

[looly]

已回复。