Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. B.W. Kernighan.
除錯的確是很不受歡迎的工作，不過你如要寫程式，就不能面對這一道關卡，在我看，唯一的辦法是學習正確寫程式之道。Brian W. Kernighan與Dennis Ritchie是兩位發明C語言的大功臣，Kernighan曾經提出寫優良程式的原則：KISS(Keep It Simple, Stupid或Keep It Short and Simple)，這個原則是說：設計簡單必須是關鍵目標，同時要避免不必要的複雜，這個原則印證在Unix作業系統，Unix有一句諺語：Small is beutiful. Unix裡面的程式，他們稱為tool，每一tool又簡又短(超過50行算是大tool)，而且只做一件事，Tool可以用pipe(|)機制連結成為指令，稱為pipeline，這是很有趣而且優美的程式撰寫法，寫程式的人士何不研究這種撰寫程式的技巧，我想，除錯也許就不至於如此痛苦！
int x,y,z, w ; x= ++y*z++-w*y*z ; this statement's readability is bad. how do you explain this statement ? the clear statement should be as below ++y ; x= y*z ; z++; x = x - w*y*z ;
kiss means keep it ( programs) simple and stupid ,that is , don't use tricky programming skills to write your programs . Make statements clear and maintainable.
E.W. Dijkstra(提倡Structured Programming那位老兄，已逝)曾說：『Program testing can be used to show the presence of bugs, never to show their absence.』，這句話大概已有三十年以上歷史，但是我想至今仍然適用，(我不知那位測試專家對這句話能提供意見)，重點是，測試是不能顯示bugs的不存在。我記得大約196幾年，美國NASA打了一隻太空船要探測火星(?)，打上太空後不久該太空船不知所終，檢查結果，據說是地面控制太空船的電腦軟體有一行statement有錯，我想NASA不可能不徹底做過測試，這就應了Dijkstra測試不能顯示bugs的不存在的說法。Fred Brooks在他的『No Silver Bullet: Essence and Accidents of Software Engineering』一文提到：「軟體的複雜是基本特性而非一種偶然」，換言之，軟體的複雜是與生具來，因此不管程式寫得如何技巧，除錯仍然很吃力，這麼說，測試是否無用？其實不然，至少測試可以顯示bugs而除之，我個人的想法是盡量不要犯錯，如何做到？提升軟體發展技術的「抽象層次」(level of abstraction)是一種方法，這些技術如Agile Methods或Model-Driven Achitecture(MDA)，都是高抽象層次的發展方法，尤其MDA可以將models自動化轉換成程式，系統是由 models來描述，而models與程式一樣可執行，因此保養models而非程式，保養models總比保養程式(包括除錯等)的抽象層次高，因此比較容易，容易就比較不會犯錯，也就容易對付複雜，我無法在張貼意見欄內詳細說明這種MDA或Agile Methods的軟體發展技術，有興趣可參考登載在部落格的4篇文章：『漫談模式驅動架構』(一、二、三) 以及『利用「原型樣式」快速發展軟體』，順便也參考『漫談Agile Modeling』一文。
除錯的確是很不受歡迎的工作，不過你如要寫程式，就不能面對這一道關卡，在我看，唯一的辦法是學習正確寫程式之道。Brian W. Kernighan與Dennis Ritchie是兩位發明C語言的大功臣，Kernighan曾經提出寫優良程式的原則：KISS(Keep It Simple, Stupid或Keep It Short and Simple)，這個原則是說：設計簡單必須是關鍵目標，同時要避免不必要的複雜，這個原則印證在Unix作業系統，Unix有一句諺語：Small is beutiful. Unix裡面的程式，他們稱為tool，每一tool又簡又短(超過50行算是大tool)，而且只做一件事，Tool可以用pipe(|)機制連結成為指令，稱為pipeline，這是很有趣而且優美的程式撰寫法，寫程式的人士何不研究這種撰寫程式的技巧，我想，除錯也許就不至於如此痛苦！
回覆刪除KISS. Keep it simple and stupid.
回覆刪除這句話有點不懂。
回覆刪除for example , see following expression .
回覆刪除int x,y,z, w ;
x= ++y*z++-w*y*z ;
this statement's readability is bad.
how do you explain this statement ?
the clear statement should be as below
++y ;
x= y*z ;
z++;
x = x - w*y*z ;
kiss means keep it ( programs) simple and stupid ,that is , don't use tricky programming skills to write your programs . Make statements clear and maintainable.
解釋的很不錯。這個諺語越看越棒。
回覆刪除諺語應該請教授提供一個『諺語解析』。要不然有些會有點看不懂。
E.W. Dijkstra(提倡Structured Programming那位老兄，已逝)曾說：『Program testing can be used to show the presence of bugs, never to show their absence.』，這句話大概已有三十年以上歷史，但是我想至今仍然適用，(我不知那位測試專家對這句話能提供意見)，重點是，測試是不能顯示bugs的不存在。我記得大約196幾年，美國NASA打了一隻太空船要探測火星(?)，打上太空後不久該太空船不知所終，檢查結果，據說是地面控制太空船的電腦軟體有一行statement有錯，我想NASA不可能不徹底做過測試，這就應了Dijkstra測試不能顯示bugs的不存在的說法。Fred Brooks在他的『No Silver Bullet: Essence and Accidents of Software Engineering』一文提到：「軟體的複雜是基本特性而非一種偶然」，換言之，軟體的複雜是與生具來，因此不管程式寫得如何技巧，除錯仍然很吃力，這麼說，測試是否無用？其實不然，至少測試可以顯示bugs而除之，我個人的想法是盡量不要犯錯，如何做到？提升軟體發展技術的「抽象層次」(level of abstraction)是一種方法，這些技術如Agile Methods或Model-Driven Achitecture(MDA)，都是高抽象層次的發展方法，尤其MDA可以將models自動化轉換成程式，系統是由 models來描述，而models與程式一樣可執行，因此保養models而非程式，保養models總比保養程式(包括除錯等)的抽象層次高，因此比較容易，容易就比較不會犯錯，也就容易對付複雜，我無法在張貼意見欄內詳細說明這種MDA或Agile Methods的軟體發展技術，有興趣可參考登載在部落格的4篇文章：『漫談模式驅動架構』(一、二、三) 以及『利用「原型樣式」快速發展軟體』，順便也參考『漫談Agile Modeling』一文。
回覆刪除我總有一種也許不太對的想法，發展軟體最好避免錯誤，但實際上是不可能，因此最好使用比較不會犯錯的技術來發展(包括優良的軟體管理)，如前所述Agile Methods或MDA，這兩種技術是目前世界上許多人接受而且使用的軟體發展方法，當然高抽象層次的軟體發展方法並不僅止於這兩種方法。
以上長篇小論不知是否能夠滿足樓上匿名所要的『諺語解析』？如果不能則請再張貼意見。
我想更簡單的說，若是用100%的智慧寫出了超級精巧的程式，去哪裡搞來200%的智慧來除錯？
回覆刪除