大概從 5 年前，我開始大量使用 OTV，從當時寫的一篇文章開始 Link1 。在大量使用 OTV，並取適當變數名之後，即使註解寫的不多，也不會造成閱讀的困難。當然，是否容易閱讀可能取決於個人。但後來我想清一件事，我好像沒義務寫到每個人都讀的懂，但至少自己在半年之後還能讀的懂，這樣就夠了。
OTV 的問題在於有很多人誤以為這樣會降低執行效率。對某些語言也許會，例如 Python，這類語言因為是在 runtime 編譯，因此無法做太多 optimization。但對於 C/C++/Java 這類語言，如果會降低效能，那就是 compiler 的問題了。不如等到實際 profiling 之後，再針對 bottleneck 做局部改善。(前幾天 ptt 好像有人在抱怨主管時，也討論到類以問題)
你的 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 了，沒有必要省成這樣…