程式設計 /z/programming
6
A Nickel's Worth: A Guide to Naming Variables (a-nickels-worth.blogspot.tw)
8 則討論 IngramChen 張貼於

koji 積分 1

後面提到的如果變數定義跟使用位置很近的話就可以簡潔寫還不錯...

回應

Thinker 積分 2 編輯於

大概從 5 年前，我開始大量使用 OTV，從當時寫的一篇文章開始 Link1 。在大量使用 OTV，並取適當變數名之後，即使註解寫的不多，也不會造成閱讀的困難。當然，是否容易閱讀可能取決於個人。但後來我想清一件事，我好像沒義務寫到每個人都讀的懂，但至少自己在半年之後還能讀的懂，這樣就夠了。

OTV 的問題在於有很多人誤以為這樣會降低執行效率。對某些語言也許會，例如 Python，這類語言因為是在 runtime 編譯，因此無法做太多 optimization。但對於 C/C++/Java 這類語言，如果會降低效能，那就是 compiler 的問題了。不如等到實際 profiling 之後，再針對 bottleneck 做局部改善。(前幾天 ptt 好像有人在抱怨主管時，也討論到類以問題)

1
http://www.codemud.net/~thinker/GinGin_CGI.py/show_id_doc/445
回應

IngramChen 積分 1

你的 link 裡面的寫法，類似 TDD 開發流程了 (先從一個無用的結果開始，然後漸漸長大… etc)

OTV 的話，有時候是為了 debug 方便，有中間變數 breakpoint 比較好設。

OTV 多起來命名也是有點討厭就是，本文的範例裡，它說宣告和使用位置相近的話，可以縮到剩一個字：

 List<Host> hs = s.fetchHostsWithPackage(obsoleteVersions);
 Workflow w = startUpdateWorkflow(hs);

雖然作者這樣說，但我個人的經驗還是不會去寫 hs, w，最少還是會寫個單字

 List<Host> hosts = s.fetchHostsWithPackage(obsoleteVersions);
 Workflow flow = startUpdateWorkflow(hosts);

沒差幾個字，卻比較好懂，在 IDE 裡通常也是打個字頭就 auto complete 了，沒有必要省成這樣…

回應

kaif 積分 0

我個人覺得OTV的問題是讓code變多行，要多花力氣讀吧。實務上效能的問題是因為OTV的case應該很罕見吧..

回應

koji 積分 0

inline 太扯有時也會很難過就是，到最後都是一種“感覺”....

回應

csc 積分 0

最近寫/改scala特別有感啊XD

回應

whitglint 積分 0

我也都先寫 return result;

回應

kaif 積分 0

對打得每個字斤斤計較，要讓程式每個字都有意義。

回應