https://reurl.cc/OmeMaR
以下內容轉自臉書（連結如上）
https://files.catbox.moe/0pu43a.png
前幾日微軟工程師 Dave W Plummer 分享
當初微軟推出新的作業系統 Windows NT 後
要把立體彈珠台 (Pinball) 這個內建遊戲改寫到新的作業系統
於是被交派這個任務的他看了原本的程式碼
結果發現是一個超級巨型的 swtich() 語句
底下有超過五十個 case 所組成

不能亂動了

至少他還有用Switch而不是if else

switch也沒很亂吧 總比把東西亂放好

可以想像只是有點失望

很合理啊 都是用球去撞switch成五十塊反而可以讓每塊的深度不要太深

然後發現第一個case永遠為true

巨型狀態機 這不是很棒嗎?

1993年欸，那個時候上課都在用組語

永遠true更爽了 剩下49條砍掉都不怕出事= =

用switch已經是高階語言了

好奇那個年代可以呈現出那樣的彈珠彈跳感算是很厲害嗎？那時有物理引擎之類的東西了？

那個誰跟你說你應該總是使用if else還出了本書

至少不是寫成巢狀if else

二維運動反彈加個重力 不算太複雜

狀態機 沒有問題

還有什麼更好的寫法嗎？願聞其詳

以彈珠台這例子來說，用switch沒有什麼不好吧?

if else if else if else if else if else if else

至少比全都if好很多了

這個案例寫50個case或50個if else都算是合理用法

任天堂又贏

不然要一堆if else 喔 最後的判斷要把前面全都跑過

寫到50我猜是用來判斷撞到什麼 現代可能寫成物件吧

if else要判斷的只有if裡面的東西啊 switch一樣要比較如果那50個東西被彈珠撞的反應有明顯的樹狀結構

不過邏輯如果不複雜用switch也沒差

那就會寫成樹狀if else了 不過我也不是做這遊戲的

只是在這裡聽到switch這種程設課前幾堂就學到的東西覺得有點奇怪而已。身為微軟的程式猿沒有更神奇的寫法嗎…

如果處理50種碰撞都是相異的小事 那並列沒什麼問題

能寫的簡單幹嘛複雜化

彈珠檯本身就是個貼圖碰撞遊戲 不管你是要顯示外觀還是要處理彈珠碰撞 switch和if else都是最直接的選擇我個人是比較偏好if else啦 switch你還要想一下冒號換行 以及裡面如果要宣告變數可能會有什麼麻煩

這邊switch case很合理吧 每個事件都是平等的話 如果一

當然你內容夠簡單的話用哪個都沒差

只要她會動，那就沒問題。

50個case和50個else if其實看起來也差不多case裡面宣告變數反而還稍微有點問題

菜雞覺得用switch 很美（X

牛用奶頭走路.gif

至少不是用if else 外加 goto

我倒是覺得是用 X-macro 加上 array，之後套 switch-case這樣只要維護 X-macro 就好

以這張圖來說 只知道是跟這50個彈珠檯零件有關的判斷

If it works, it works

用switch會好讀嗎

這個的關鍵不是在switch，而是"巨型"。無論什麼程式碼你只要聽到某個"巨型"的東西(不管那東西是條件判斷還是函式還是其他的什麼)，那通常都會讓人類一個頭兩個大，就這樣。

看起來就是球跟場地有互動就來跑這個switch 簡單粗暴 比什麼不小心搜尋到整個包包造成卡頓 還是什麼你看這顆石頭有幾百萬面但優化0分 拍賣太多人用會壞掉 好很多

我猜碰觸物件之後該物件會觸發一個共同event，而不是每個物件有獨立的event，然後再從參數裡面帶物件的編號，所以後面的handler用switch case去處理，如果是這樣的話那會比if else好很多，包括效能的部分

我有點忘記 場上是不是可以多一顆球 這樣運作沒問題嗎

那時代的程式語言就差不多那樣吧

可以三顆噢

寫得蠻好的啊

至少不是if

switch case比if else好讀 不過要是能物件化每個物件各自處理碰撞事件會更好擴充

或者是用jumpx跳來跳去的

多球不知道如何設計 handler再傳入ball*之類的? 但又要忙多顆球的物理有點忙C++的話有種想套template method XD

如果是50物件都有獨自物理特性，沒毛病啊

看他這個圖片的案例 switch確實沒啥問題 就是很多而已

童年

我比較喜歡看if else switch還要找break不過如果內容簡單的話確實switch更合理

switch控制狀態機不是基本到不行嗎

至少不是用goto 大家就要知足 XD

難不成想看到一堆goto嗎？

原始訪談 https://youtu.be/Lmi_TuIYXYw拿到手的原始碼基本都是組合語言，核心的switch statements還有彩蛋藏在裡面，不過訪談沒說是什麼彩蛋

沒有問題吧 遊戲就是一個巨大的狀態機

Windows工作管理員也是他寫出來的

這東西開發的時候還 設計模式 物件導向還不是主流吧