※ 引述《milonga332 ( U U)》之铭言：
: 小弟多年前在一家公司上班，负责写Android App
: 公司里的神级前辈规定，写Java要避免使用getXXX/setXXX作为method的命名习惯
: 要改用readXXX/writeXXX，或retriveXXX/putXXX...之类的都可以
: 当时试着询问原因，不过只被冷眼酸了一顿
: 虽然现在已经不在该公司了，不过仍然好奇可能的理由是什么，不晓得有没有人知道呢？
写 email 问他，为何不能用标准 java bean 的写法，
他不理就算了，结案啊。
（不然你说一下公司，让在职的乡民替你问啊）
: p.s. 神级前辈似乎是死硬的微软派，对于Java十分不屑
: 也许跟C#/.net的命名习惯有关？...
跟讨论无关的引战词语就免了吧。
真实的工作环境，其实该用什么时，就会用什么。
才不管 provider 或 solution 是哪家公司出的，
只有合不合理（时程、预算、后续维护成本）的考量。
推荐阅读 [1]
Getter、Setter的用与不用
https://www.ithome.com.tw/voice/98804
Get rid of getter and setter, toward domain driven design
https://ingramchen.io/blog/2009/11/
get-rid-of-getter-and-setter-toward-domain-driven-design.html
(短：http://bit.ly/2DaJA3q)
推荐阅读 [2]
Method prefix convention
https://ingramchen.io/blog/2011/07/method-prefix-convention.html
在 naming 上不用 getter/setter 后，也得在内部对 prefix 有点共识。
>> : 要改用readXXX/writeXXX，或retriveXXX/putXXX...之类的都可以
read/write 对我来说，会想到 Disk IO
retrive 对我来说，会想到要跟 data gateway
或 storage (db, nosql, searchengine) 取资料等 network IO 的东西。
put 直觉像是做 memory data 的覆写 (如同我们对 Map 做 put 一样的动作)
我们的“禁止与惩罚”文化另人困惑的地方是，只跟你说不能、不该这么做。
或没说明建议的依循准则与背后的原因，于是传承就这么中断了。