其實很多團隊裡面有些該被時代淘汰的開發/命名/排版規範，或是該規範有其適用的 context，現在產品開發可能已經不具備該 context 了。
但團隊中的一些老鳥，可能因為沒有去確認該規範所對應的 context ，或是不明究理的一脈傳承下來的限制（就跟猴子拿香蕉就被噴水，之後的猴子都不敢拿香蕉，一拿香蕉就會被其他猴子圍毆），也可能是因為「習慣」了不想改，導致團隊開發生產力低落，又得不到對應的好處。
一個明顯的例子，就是匈牙利命名法，在靜態型別語言 + IDE 輔助之下，已經不需要把型別掛在變數名稱或方法名稱上。
另一個則是禁用 C# 裡面的 var，其實工具也都支援一鍵轉換了，當你詢問團隊成員為什麼不能用時，他們的回答是：「我也不知道，就不能用。」這時就會知道這個團隊存在著這樣的根本問題。
當然，還有那種 Data Class 身上不能有方法，或是 interface 自己是個 folder/namespace 的情況。
很多人寫程式真的是都是用背的，沒去了解背後的脈絡，沒去了解限制/規範想要達到的目的，透過犧牲一些自由度以帶來更大的效益，卻一味的遵循著「#前人的教誨」而不知其所以然，其實是很浪費的。
--
當然啦，如果是在既有的產品中，無傷大雅的 name style，我的確傾向 #一致性 優先於 #正確性，但同樣的團隊成員新寫的產品，就應該思考一下，究竟怎樣才是最有生產力、最有效益的作法。
匈牙利命名法 在 [轉錄]Re: 匈牙利命名法? - 看板SFFamily 的推薦與評價
※ [本文轉錄自 java 看板]
發信人: [email protected] (妙音鳥迦樓羅), 看板: java
標 題: Re: 匈牙利命名法?
發信站: 交大資科_BBS (Wed Oct 16 12:55:47 2002)
轉信站: Ptt!news.ntu!spring!ctu-peer!news.nctu!news.cis.nctu!cis_nctu
==> 在 [email protected] (jason) 的文章中提到:
> 在thinking in java一書中
> 附錄C的第39點說到不要用這種命名法
> 說是會造成程式難以閱讀...
> why?這種用法不就是讓程式容易閱讀嗎?
> 還有他最後一句話:讓package和class來進行name scoping
> 是什麼意思啊?
其實匈牙利命名法是在80年代初期，程式語言在變數名稱仍有過短的長度限制的時代，
微軟的西蒙亦發展出來的種能在簡短的變數名稱就能表現出變數的涵義以及特性的命名法。
不過他的問題就是畢竟那是用簡寫編出來的變數名稱，可讀性不好，使用的人要花好一段時
間去熟悉這樣的簡寫方式，才不會混淆。
然而今天各程式語言普遍已經可以使用很長的變數名稱了，打個10~20幾個字作變數名稱
也不是什麼問題。為了程式的可讀性起見，其實是可以不需再用匈牙利命名法了，可以打直
覺的變數名稱了。
例如說一個boolean變數描述要不要重繪螢幕好了
我用類似匈牙利命名法可能這樣命名:boolean bl_rpntMtr
再用現在java可以用的長變數名稱命名習慣:
boolean bl_repaintMonitor
你覺得哪一個比較容易看得懂呢?
--
MenuStory選單故事書多線小說閱讀器最新1.5.3版
https://kickme.to/menustory
妙音鳥個人音樂以及程式站
https://nmb.musizworms.org/
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>
--
「大哥！你....」
「你在以旁門左道的方法，逼自己的劍氣踰越極限﹖」
「廢話！」應雄反駁：
「什麼旁門左道﹖能夠將最強的功力提昇至無法再上的強中之強，
才是必勝的最佳戰略！」
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.107.52
... <看更多>