6
A Nickel's Worth: A Guide to Naming Variables (a-nickels-worth.blogspot.tw)
koji 積分 1

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

Thinker 積分 2 編輯於

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

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

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

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