在寫《The Nature of Code閱讀心得筆記——使用Python實作》 《The Nature of Code閱讀心得與Python實作》的第2.4節時，碰到這麼一個練習題，這個練習題要做的，是要讓在畫面中蹦蹦跳跳的球，會感受到來自畫面邊界的排斥力，球距離邊界越近，排斥力會越大。
這個練習題其實並不困難，很快就寫好了，不過在寫的當中，卻意外對dictionary這個玩意兒的使用時機和使用方式，有了新的想法。好笑的是，這一切，都是因為想偷懶，不想寫註解。
很顯然的，必須要知道球和四個畫面邊界間的距離，才能夠去設計排斥力的大小。這個其實不難辦到，只要在球的class中，增加一個計算離邊界距離的method就可以了。這個method，一開始是這麼寫的這裡頭的width和height，是畫面的寬度和高度；location.x和location.y，則是球的位置；而傳回的distances中，則放了球距離上、下、左、右四個邊界的距離。
計算的部分寫好了，再來就該把註解寫一寫，免得之後要用時，忘了distances的四個元素，個別是指到哪個邊界的距離。
正要寫的時候，突然覺得挺麻煩的，寫了半天的註解，就為了等到呼叫這個method時，能夠查看distances的哪個元素指的是哪個距離。先前在安排distances[0]～distances[3]所指的距離時，就曾想過，這個順序是逆時針的上、左、下、右，或者順時針的上、右、下、左，還是上、下、左、右，會比較順口容易記得？這可是會影響到呼叫這個method時，是不是容易搞錯順序的機率。除此之外，也會影響到寫程式的速度，畢竟如果是個很讓人彆扭的順序，那就得時不時地去注意有沒有搞錯順序，這樣寫程式的速度快得起來才有鬼。最後之所以用上、下、左、右這個順序，也就是因為唸起來覺得比較順口。當然啦！其他人是不是也覺得這樣的順序比較順，那就不得而知了。
那該怎麼辦呢？瞪著螢幕好一會兒，就是覺得渾身上下懶洋洋的，不想動手。不想寫註解，但卻又希望能看到註解，充分具體展現了拖延症該有的症狀。
沒有寫註解，但是有看到註解。這什麼跟什麼啊！禪宗的公案嗎？
現在傳回的distances是list，有沒有什麼其他的資料型態可以把註解寫在裡頭的？Python基本的資料型態就那一些，有哪個可以辦到呢？
咦？！那個dictionary不是有key嗎？把key當註解來用不就得了！
突然間，拖延症痊癒了，全身充滿幹勁，沒兩下就寫好了。新版的distances_to_edges()長這樣：
def distances_to_edges(self):
distances = {}
distances["top"] = self.location.y
distances["bottom"] = self.height - self.location.y
distances["left"] = self.location.x
distances["right"] = self.width - self.location.x
使用時，可以這樣寫
distances = ball.distances_to_edges()
這時候，distances["top"]、distances["bottom"]、distances["left"]、distances["right"]就是ball距離上、下、左、右邊界的距離，完全不用去管順序，那幾個key就說明了一切。當然啦，如果覺得那幾個key還不夠清楚，也可以改成其他想要的字眼，像是"to_top"之類的。不管怎麼寫，最終極的目標，就是完全不需要註解，也可以輕輕鬆鬆看懂程式想要做什麼。
就這樣，因為拖延症犯了想偷懶，結果是對dictionary的使用時機和使用方式，有了新的體會。原來，dictionary這樣用，也是可以的啦！
