※ 引述《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 一樣的動作)
我們的「禁止與懲罰」文化另人困惑的地方是，只跟你說不能、不該這麼做。
或沒說明建議的依循準則與背後的原因，於是傳承就這麼中斷了。