Re: [問題] 新手發問 "!!"的意思

[yauhh (喲)]

※ 引述《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)
推 teslare:agree, 程式語法冷僻不可怕，查一下就好
→ teslare:怕的是邏輯不清或沒考慮edge condition
→ teslare:那樣之後接的人會非常非常慘
推 ShadowMask:
→ popcorny:我是覺得最起碼要用Macro包一下
→ popcorny:#define ISTRUE(x) (!!(x))
→ popcorny:可讀性跟你說的其實沒有那麼衝突
推 PCIT:樓上的建議不賴
推 ppc:像拔河一樣
→ apflake:這種說法在軟體工程上是不太正確的,你寫的
→ apflake:程式可能是三十年後某個倒楣的工程師要維
→ apflake:護,大型專案參與的人很多,複雜度越來越高,
→ apflake:溝通,爭吵,或是讓別人花時間讀懂都是成本
推 selfhu:除了短小以外，可轉化成查表指令，速度更快
→ yoco315:任何程式設計師都能寫出令人費解的程式碼
→ yoco315:而只有一流的程式設計師可以寫出讓人一眼
→ yoco315:就能直覺看懂的程式碼... @_@
→ yoco315:重點不是大家能不能看懂,花點時間,或是上
→ yoco315:網問一下,最終誰都能看懂。冷僻的程式碼
→ yoco315:任何學過兩年程式設計的人都可以寫出一推
→ yoco315:問題是只有受過良好訓練的人,才能寫出別人
→ yoco315:能一眼看懂的東西,長期大範圍的累積下來
→ yoco315:這就構成的軟體的品質跟可維護性
→ ykjiang:另外，建議以 BIT(X) 取代 ISTRUE(X)