成為卓越程式設計師的38項必修法則

46

| 第五章：基礎程式的過往陰魂

原始的版本還有另一個問題：重新發明輪子。最佳的做法是直接使用必定存在的

std::max

內建函式。事後看來，這很明顯：[Page-41]

// 不要宣告任何 max 函式

void even_better_example()

{

int a = 3, b = 10;

int c = std::max(a,b);

}

如果重來一次的話，你會避免做這種事情。但是在當時，你不知道典型表達風格是什

麼。

這是一個簡單的範例，但隨著語言增加新的功能（例如 lambda），你現在寫的程式可能

會與之前幾代的程式碼有很大的不同。

設計決策

我真的用 Perl 來寫那個東西嗎？當時我在想什麼？！我真的使用這種過度簡化的排序演

算法嗎？我真的親自手寫所有的程式碼，而不是使用內建的程式庫？我真的這麼無謂地

將這些類別結合在一起？我真的不能發明一個更乾淨的 API ？我真的將原始碼管理留在

用戶的程式碼中？我可以看到許多潛在的 bug 及漏洞潛伏在那裡！

當你學得更多，就會瞭解有更好的方式可以用程式碼實做你的設計。這是經驗之談。你

犯下一些錯誤、閱讀一些不同的程式碼、與有才華的程式員共事，會很快地發現你的設

計技能已經提升了。

Bug

或許這是讓你回去查看舊基礎程式碼的原因。有時用新鮮的眼光回顧舊程式，會讓你看

到當時錯過的明顯問題。當你被某些類型的 bug 咬過之後（通常常見的典型表達風格會

讓你遠離它們），你自然會開始在舊程式中看到潛藏的 bug。這是程式員的第六感。

結論

|

47

結論

遺憾無法彌補生命中的機會被誤用。 ...