※ 引述《LPH66 (-858993460)》之銘言： : 於是 !!T1 + 2 * !! T2 + 4 * !! Carry 這個算式 : 將三件事 (T1 != 0, T2 != 0, Carry != 0) 編碼成一個整數 : 若三者都為 0 則它會算出二進位的 000 = 十進位 0 : 若只有 T1 非 0 則它會算出二進位的 001 = 十進位 1 : 若只有 T2 非 0 010 = 十進位 2 : 若只有 Carry 非 0 100 = 十進位 4 : 等等 : 這樣就能以 switch 一次判斷三個條件的真假 : 你可以注意到這個 switch 裡的 case 有註解寫說這是什麼情況 : 就是這麼來的 : → final01:程式設計師有必要那麼懶嗎 211.21.157.199 03/10 12:19 通常我們會遇到一些溝通及思考上的懶人,直接看到結果去推原因. 像這件事情,專案管理者指派一個task給程式設計者,程式設計者知道requirement需求, 然後經過unknown process,產生了product即程式維護的結果. function task(requirement) { ...(unknown processes) return product; } 在專案管理者眼中,明明很清楚程式設計者只知道requirement和product,但是在 專案管理者腦中會自動補完那段unknown process,最後會變成他們的一句話: "如果我是老闆,看到這樣的程式碼我會fire掉寫這程式碼的人." 但是實際上不是. 在程式設計者的眼中,有可能是經過這樣的程序: 1. 我要做一個函數是將 t1, t2, carry 對應到 0~7, 分別代表八種情況. 2. 用 if-else 寫一次, "靠!一層又一層的好醜." 3. 分成一段又一段的if, "這樣子程式拉那麼長,看了後面忘了前面." 4. 使用8421編碼 (即本文所講的方法), "感覺應該不錯." 這些 1 2 3 4 點程序的數量和內容不一定是這個樣子,而是像人性一樣變化多端. 總而言之,一段看起來精細的程式碼,是經過多次整修之後的結果, 而不是一開始程式設計者只打算用這種複雜的構思方式寫程式. 有時候我們看到一些看不懂的程式,應該先看自己有沒有能力從陌生的程式碼理出頭續. 如果沒辦法看懂,究竟是要檢討自己閱讀能力有限,還是檢討別人的程式碼有毛病呢? 這就看各人的修養及容忍力. (我個人認為,從程式碼靜態結果去反推程式設計者的思考方式正確與否,是蠢蛋在 做的事. 程式碼是反覆修改而得到最後的狀態,並不代表這個寫程式的人心裡全都 是怎麼想的.) 關於程式合作方面,有人說程式最好寫得好維護. if-else很好維護啊,邏輯順序清楚, 但是恰好就因為有*邏輯順序*,所以如果維護者沒辦法抓得到那個邏輯順序,程式 瞬間就變成難以維護的東西. 很多人應該都碰過程序式的程式,從頭到尾漏漏長, 每一段都好簡單,但是要抓錯發生在什麼位置就要從頭到尾看每個變數的狀態, 那樣子叫做好維護嗎? 相較來看,像本文這種 !!T1 + 2 * !! T2 + 4 * !! Carry ===> int 程式短小,值域明確,只差語法上面比較不好讀的這種情況,表面上看起來不好維護, 實際上如果這一段程式有算錯,要修改時,UnitTest自動測試程式做下去,各種測試資料 刷個幾次,如果正確通過就完成,維護的時間可能短少很多. 本人是很懼怕那種看到程式稍微難讀就該該叫的合作者,遇到那種人,程式難維護或 容易維護都沒關係,最麻煩的就是程式寫複雜一點點就吵不完. 溝通上問題比較麻煩. (說穿了數學差就承認嘛,嫌程式複雜是哪一招...) 抱歉一點點題外的牢騷. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.160.108.73 ※ 編輯: yauhh 來自: 218.160.108.73 (03/10 13:28)