這樣用dictionary也是可以的啦!

這樣用dictionary也是可以的啦!

更新於 發佈於 閱讀時間約 5 分鐘

在寫《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這樣用,也是可以的啦!


avatar-img
ysf的沙龍
15會員
140內容數
寫點東西自娛娛人
留言
avatar-img
留言分享你的想法!
ysf的沙龍 的其他內容
「蛤?!居然當機!」瞪著畫面凍結的螢幕,心裡一面嘀嘀咕咕,一面敲著鍵盤,企圖死馬當活馬醫,看看能不能免去重開機的麻煩。 一切的努力都是徒然,這是徹底的當機!滑鼠、鍵盤完全失去作用,只餘關電源強迫關機一條路可走。 在重開機的當兒,一面看著螢幕有沒有顯示異常的訊息,一面開始分析可能的當機原因。
看來這應該是pygame的bug,而不是自己寫的程式有問題。為了進一步證實這個猜測,重寫了一個單純只畫出圓球的程式,除了畫出不同位置的圓球之外,沒有任何其他作用
俗話說「萬事起頭難」還真是一點也沒錯,從開始動筆寫《The Nature of Code閱讀心得筆記——使用Python實作》,到寫完頭一章,再到把文章放上網站開始發表,總共隔了快三個月的時間。
不知道為什麼,原本相安無事的兩個人,突然間看對了眼,開始出雙入對、形影不離。這除了讓人看了很不順眼之外,也很浪費時間。雖然想盡辦法要拆散他們,但都沒成功。逼不得已,只好狠下心來,冒險將一切抹除,讓他們走完「成、住、壞、空」最後的階段,輪迴至下一輪的「成、住、壞、空」。只是沒想到
天啊!怎麼這麼混亂!網路上有一卡車的文章在談class、object、instance有什麼不同;在Stack Overflow中,關於object和instance間的差異,也一再有人問起。只是啊只是,看了一大堆的討論、解釋,似乎是懂了,但又總覺得不踏實,就好像漂蕩在太空中,明明目標就在眼前,但無
在Python官網的Glossary第一次看到「duck typing」這個詞的時候,真的是很疑惑:Python怎麼會跟鴨子扯得上關係?更疑惑的是,那還是隻會打字的鴨子!
「蛤?!居然當機!」瞪著畫面凍結的螢幕,心裡一面嘀嘀咕咕,一面敲著鍵盤,企圖死馬當活馬醫,看看能不能免去重開機的麻煩。 一切的努力都是徒然,這是徹底的當機!滑鼠、鍵盤完全失去作用,只餘關電源強迫關機一條路可走。 在重開機的當兒,一面看著螢幕有沒有顯示異常的訊息,一面開始分析可能的當機原因。
看來這應該是pygame的bug,而不是自己寫的程式有問題。為了進一步證實這個猜測,重寫了一個單純只畫出圓球的程式,除了畫出不同位置的圓球之外,沒有任何其他作用
俗話說「萬事起頭難」還真是一點也沒錯,從開始動筆寫《The Nature of Code閱讀心得筆記——使用Python實作》,到寫完頭一章,再到把文章放上網站開始發表,總共隔了快三個月的時間。
不知道為什麼,原本相安無事的兩個人,突然間看對了眼,開始出雙入對、形影不離。這除了讓人看了很不順眼之外,也很浪費時間。雖然想盡辦法要拆散他們,但都沒成功。逼不得已,只好狠下心來,冒險將一切抹除,讓他們走完「成、住、壞、空」最後的階段,輪迴至下一輪的「成、住、壞、空」。只是沒想到
天啊!怎麼這麼混亂!網路上有一卡車的文章在談class、object、instance有什麼不同;在Stack Overflow中,關於object和instance間的差異,也一再有人問起。只是啊只是,看了一大堆的討論、解釋,似乎是懂了,但又總覺得不踏實,就好像漂蕩在太空中,明明目標就在眼前,但無
在Python官網的Glossary第一次看到「duck typing」這個詞的時候,真的是很疑惑:Python怎麼會跟鴨子扯得上關係?更疑惑的是,那還是隻會打字的鴨子!