别。事实上,你不能把它叫做什么Util。也许你会认为我是一个在背后吹毛求疵的讨厌的家伙。不,我不是。
Util 是 Utility 的简写,有用的东西的意思。如果你找到这样的东西,它也许真的会对你非常的有用。可问题就在这儿。你并不能总是找到它们。当你在研究一个别人写的代码库时,有些东西并不总是想你想象的那样一目了然。此时你唯一的希望就寄托于别的程序员能把程序以一种易于察觉的方式命名。否则你就找不到它了。
事实上,你不仅会错过了它,最终你很可能会重复用功,你知道,你最终很可能写出一个草率的辅助函数,把它放到一个叫做FormatHelper 的类里,而没有发现有一个叫FormatUtil的类。当Jack来了后,他自己也写了一个,放到了一个叫做FormatServices的文件里。为什么?因为最开始我们就没有对命名太留意。
对于理解一段代码,唯一能指望的、唯一能依赖的,就是代码本身。我不想打搅同事来弄清楚一段程序是如何工作的,或某个参数是什么意思,或为什么会需要这段代码,或我自己又编写一遍。我们应该利用这些编程语言,用合理的命名来交流、理解。
下次当你需要对一个类进行命名时,以它能做什么来命名。如果你发现它的这个名字太有说服力了,那你是于己于人都做了一件好事。
这就是为什么我对命名这么挑剔。因为,不管你是怎么想的,除非它自己是显而易见的,它不可能做到显而易见。而对于你,它的创造者,它永远都是显而易见的。而对于我,不是。
Util, Service, Helper, Manager … 所有的这些都是没有意义的 …
我的大部分工具类代码都叫作util,以前都叫作handler,后来批量都改了名,留了部分事件、文件处理的交handler。
看了这个文章,觉得很搞笑。
取个合适的名字实在太困难了,有时候自己都找不到了,更不用说别人了。
我就在维护一个所有业务方法都叫 xxxHelper 的项目,shame
也许一片万艾可才是原始设计者真正需要的 Helper?
不知道有没有更好的命名方式,我的大部分工具类都是util为后缀
我也很讨厌util这类的名字。我觉得这是一种思考不充分的表现。
但是得到好名字需要正确理解命名对象的作用以及在代码框架中的位置,还涉及程序员的表达能力。甚至还涉及到使用语言的表达能力。
很多util打头的函数,无视ing
确实对命名有强迫症…
好的命名风格让人赏心悦目,不会让人有排斥心里,自然代码读起来如行云流水,更好的理解原作者的意图…
我通常把那些公共的,并且只有静态函数,没有实例,没有属性的类放到util里,Helper是有实例的,有属性的这样的类.
如果util命名有问题,有更高明的办法吗?StringUtils, XMLUtils 呢?说到底,因为util的范畴太广,容易误用就把一堆静态方法凑在一块。而如果是组织良好的util,也未尝不可吧。
团队使用同一种习惯即可。
我看完文章,看懂了吐槽点,但实际开发中,也没发现用Util有什么不好,不好的是混用Util/Helper
我认为是utilities的意思