- P7 把主要精力集中于構(gòu)建活動,，可以大大提高程序員的生產(chǎn)率。
在最近的一個項(xiàng)目中,，對于這一點(diǎn),，我是深有體會。我們花了很長的時間做設(shè)計(jì),，結(jié)果接下來的許多工作都在愉快的心情下完成,。我覺得 P28 的那個食物鏈的例子更有說服力，健康的生態(tài)環(huán)境中,，海鷗吃新鮮的鮭魚,，鮭魚吃新鮮的青魚,，青魚吃新鮮的水蝽。這是一條健康的食物鏈,。 如果環(huán)境被污染了,，水蝽在污染的水域游泳，那么海鷗,，食物鏈的最后一環(huán)吃下的不僅僅是是不健康的鮭魚體內(nèi)的垃圾,，還有青魚，水蝽體內(nèi)的污染物,。軟件開發(fā)中,，架構(gòu)師吃掉需求，設(shè)計(jì)師吃掉架構(gòu),，程序員，軟件食物鏈的最后一環(huán),，消化掉設(shè)計(jì),。如果一開始就被污染了，我們就不要指望程序員快樂了,。整個軟件都會具有放射性,，周身都是缺陷，絕對導(dǎo)致程序員脾氣暴躁,、營養(yǎng)失調(diào),。在我們規(guī)模不大的團(tuán)隊(duì)里，一個人身兼數(shù)職,，傷害更大,。所以，項(xiàng)目一開始就決定了它能否成功,。
- P7 源代碼——往往是對軟件的唯一精確描述
其實(shí)我們不必為沒有精確的文檔沮喪,，不是嗎？
- P13 常見的軟件隱喻
好的隱喻可以讓我們思考更多的問題,，并走上正確的道路,。我們是在 Writing Code，還是 Growing a System 還是 System Accretion 或是 Building Software ? 做不同軟件有不同的方法,，不要拘泥,。
- P24 避免使用錯誤的方法制造正確的產(chǎn)品
往往我們在軟件開發(fā)中會很強(qiáng)調(diào)測試。的確,、測試是質(zhì)量的保證,。但是測試只保證有質(zhì)量的代碼，卻不保證有質(zhì)量的設(shè)計(jì),。
- P42 需求的 checklist
其實(shí)我們不必去照本宣科的寫需求分析書什么的,，做需求分析即使是在大腦中,，口頭交流上完成，也是有這么一個過程,。落下文字固然是好的,，但并不是重點(diǎn)。關(guān)鍵在于做不做,。是否詳細(xì)定義了系統(tǒng)的全部輸入,，包括來源、精度,、取值范圍,、出現(xiàn)頻率。是否詳細(xì)定義了系統(tǒng)全部輸出,，包括目的,，精度，取值范圍,、出現(xiàn)頻率,，格式？是否定義了機(jī)器內(nèi)存和剩余磁盤空間的最小值,？是否詳細(xì)定義了系統(tǒng)的可維護(hù)性,，包括適應(yīng)特定功能的變更、操作環(huán)境的變更,、與其他軟件的接口的變更能力,？ 書中列的遠(yuǎn)比我這里列出的多，非常值得一讀,。定下這些是很重要的,，我覺得合理的游戲開發(fā)，是有一個相對穩(wěn)定的策劃方案,，和一些已經(jīng)完成完成的美術(shù)資源,。大部分的變更都留在下一版本去做。策劃和美術(shù)永遠(yuǎn)為下一個版本工作,，而程序可以根據(jù)相對穩(wěn)定的需求做設(shè)計(jì),。這樣做，即使第一個版本是不可玩的,，扔掉,，也是能讓游戲最終成功。
- P46 數(shù)據(jù)設(shè)計(jì)
我曾經(jīng)很迷惑項(xiàng)目文檔到底要寫什么,？這里列舉的一些東西解開了我一些疑惑,。如果你選擇使用一個順序訪問的列表表示一組數(shù)據(jù)，就應(yīng)該說明為什么順序訪問比隨機(jī)訪問更好,。（往往隨機(jī)訪問更為高效）在構(gòu)建期間,，這些信息讓你能洞察架構(gòu)師的思想,。在維護(hù)階段，這種洞察力是無價之寶,。 后面 P58 有個更為有趣的例子：Beth 想做丈夫 Adbul 家祖?zhèn)鞯臒跞?。Adbul 說，先撒上胡椒和鹽,，然后去頭去尾,，最后放在鍋里蓋上蓋子燉就好了。Beth 就問了,，“為什么要去頭去尾呢,？” Abdul 回答說，我不知道,，我一直這么做,，這要問我媽。他打電話回家一問,，母親也說不知道,，她一直這么做，這個問題要問奶奶,。母親就打了個電話給奶奶，奶奶回答說,，“我不知道你為什么要去頭去尾,，我這么做是因?yàn)槲业腻佁×搜b不下”:D 架構(gòu)應(yīng)該描述所有主要決策的動機(jī)。
- P48 國際化和本地化
國際化常常被稱為 i18n 是因?yàn)?Internationalization 這個單詞太長了,，I 和n 之間有 18 個字母,。同理，通常本地化簡寫為 l10n ,。這個工作一定要在構(gòu)架期想好啊,，到底我們需不需要 i18n 或者支持 l10n 就夠了，到底用 UTF-16 還是 UTF-8 還是 ascii 串就可以,。是代碼中嵌入字串,，還是封裝到一個類，還是可以放去一個配置文件,。我們現(xiàn)在的項(xiàng)目,，一開始考慮岔了，結(jié)果后來花了很多精力重構(gòu),。好在發(fā)現(xiàn)問題不算晚,，否則代價更高。引申的想一想,，發(fā)現(xiàn)問題我們應(yīng)該最早的解決,，不要怕做出錯誤的決定,，因?yàn)楦膳碌氖牵庾R到錯誤后,，因?yàn)楹ε滦拚e誤的代價過大,，而一拖再拖。代碼的 bugfix 大家都知道應(yīng)該立刻做,，但是設(shè)計(jì)失誤卻容易被放過,，將就著做下去。
- P51 過度工程
這個問題把握好并不容易,。一方面,，我們希望系統(tǒng)健壯，如果組成系統(tǒng)的各個部分只在最低限度滿足健壯性要求,，那么整體通常是達(dá)不到要求的,。軟件健壯性不取決于最薄弱的一環(huán)，而是等于所有薄弱環(huán)節(jié)的乘積,。構(gòu)架應(yīng)該指出每個部分,，程序員為了謹(jǐn)慎而寧可做過度工程，還是做出簡單的能工作的東西就夠了,。有些東西是不應(yīng)該過分花精力的,，這個錯誤我們也犯過，尤其一些一開始就知道以后很可能要重構(gòu)的部分,，大量的精力花在里面很浪費(fèi),。
- P62 選擇編程語言
我曾經(jīng)也覺得 C++ 是萬能的，這種想法很多 C++ 程序員也有,。但是無可否認(rèn),，每種語言的表達(dá)力是不同的。書在這頁有一張表,，如果 C 的表達(dá)能力是 1 的話,，C++ 和 Java 就是 2.5 。而 perl 和 python 卻有 6 ,。這就是我們選擇游戲邏輯腳本編寫的原因之一,。另外對語言的熟悉程度是很影響程序員的效率的，所以我們不能獨(dú)立的看語言本身的表達(dá)能力,。P63 有個例子,，用一群 Fortran 背景的程序員去用 C++ 編寫一個新系統(tǒng)，結(jié)果他們編寫出的是偽裝成 C++ 的 Fortran 代碼,。他們扭曲 C++ 來模擬 Fortran 的不良特性并且忽略了 C++ 豐富的面向?qū)ο竽芰?。我們這里有個現(xiàn)成的例子，一個 C++ 程序員用 C++/C 的方式寫 Lua ,，結(jié)果可想而知,。到現(xiàn)在我還在叮囑他,，一定要理解，再理解 Lua ,。lua 不是 C ,。
- P68 Programming into a Language
注意，這里是 into 而不是 in ,。書這里用了一個 vb 的例子來說明,，恰好我也有個例子。我們現(xiàn)在用 C++ 構(gòu)建系統(tǒng),，C++ 里有個相當(dāng)麻煩的東西,，就是單件的生存期問題。一個 singleton 到底什么時候創(chuàng)建出來,，什么是否析構(gòu),，相信很多 C++ 程序員在構(gòu)建大系統(tǒng)的時候都頭痛過。據(jù)我所知,，我們公司別的項(xiàng)目的同事到現(xiàn)在還在頭痛這個問題,。這次我做了一個約定，禁止任何模塊的代碼構(gòu)造靜態(tài)對象,，也就是說,，任何在 main 函數(shù)前自動的對象構(gòu)造過程和 main 函數(shù)之后的自動析構(gòu)過程都是不允許的。然后我們有一整套管理單件的方法供使用,，這個問題被很好的解決了,。我們再也沒有為某個單件什么時候構(gòu)造出來的，或是為什么他提前析構(gòu)了的問題煩惱過,。
- P78 管理復(fù)雜度的重要性
我們做軟件，就是在和問題的復(fù)雜度做斗爭,。有三個問題需要注意：用復(fù)雜的方法解決簡單的問題,；用簡單但錯誤的方法解決復(fù)雜的問題；用不恰當(dāng)?shù)膹?fù)雜方法解決復(fù)雜的問題,。
- P80 high fan-in 和 high fan-out
高內(nèi)聚,，低耦合很容易被重視。但是高扇入低扇出有時候會被忽略,。這里是說,，我們應(yīng)該盡量的大量的使用某個低層次上給定的類(high fan-in) 而每個類都應(yīng)該盡量少使用其他的類(控制在7個之下)。
- P83 子系統(tǒng)間盡量減少聯(lián)系
書里的例子很貼切,。一個通用的規(guī)則是,，如果 A 系統(tǒng)用到 B ，B 又用到 C ,，那么 C 就不要再用到 A 了,。系統(tǒng)層的設(shè)計(jì)圖應(yīng)該是無環(huán)圖,。
- P91 封裝不僅僅是有簡化過的模型看到復(fù)雜的概念，而且同時還不能讓你看到復(fù)雜概念的任何細(xì)節(jié)
隱藏信息的重要性毋庸質(zhì)疑,。所以我們現(xiàn)在不僅用 C++ 的 private 隱藏信息,。還用接口的方法，不在頭文件暴露任何設(shè)計(jì)細(xì)節(jié),。另外,，任何一個不滿足現(xiàn)狀的程序員，對自己以前的代碼一定不會滿意,。但是復(fù)用老的不滿意的代碼并非壞事,。我們需要做的是，重用的時候,，把老的東西隱藏起來,。
- P99 預(yù)料不同程度的變化
好的設(shè)計(jì)人員應(yīng)該對以后可能變化的部分很敏感。這點(diǎn)很有體會,，我自己就是這樣一步步過來的,。做一個決定之前，想想如果他做錯了的后果,。估計(jì)未來改變的成本,，以作出合適的設(shè)計(jì)，非常的重要,。系統(tǒng)為了適應(yīng)每種變化而做過度設(shè)計(jì)又是不合適的,。到底怎樣設(shè)計(jì)，需要良好的感覺,。
- P101 耦合的種類
松散耦合是每個系統(tǒng)設(shè)計(jì)人員所追求的東西,。但是其標(biāo)準(zhǔn)往往把握不準(zhǔn)。舉個簡單的例子,，不一定恰當(dāng),。在我最早的設(shè)計(jì)里，系統(tǒng)把坐標(biāo)這個東西封裝成一個叫做 point ,，以后參數(shù)傳遞都傳 point * ,，而不是 x,y 。這看使很合理,。但是,，這的確增加了耦合度。因?yàn)槊總€類都需要知道 point 的細(xì)節(jié),。很多情況下,，用簡單類型做參數(shù)傳遞反而更合適。(到底傳 point * 還是 x,y 依舊要根據(jù)實(shí)際情況靠量) 參數(shù)過多也會導(dǎo)致耦合度的增加，從這個角度看,，x,y 是兩個參數(shù),， point * 是一個參數(shù)。關(guān)于耦合程度的問題,，沒有絕對唯一的標(biāo)準(zhǔn),。書里的闡述和總結(jié)非常值得一看。
- P103 查閱常用的設(shè)計(jì)模式
設(shè)計(jì)模式這個東西,，給程序員帶來的最大的好處就是增加了交流的便捷,。一個人可以思考的深度取決于他用于思考的語言掌握的詞匯量。設(shè)計(jì)模式也可以給程序員帶來這種便捷,。其實(shí)常用的設(shè)計(jì)模式,，即使你沒有看過《設(shè)計(jì)模式》這本書，只要你是一個經(jīng)驗(yàn)豐富的程序員,，這些估計(jì)大多考慮過,。但是，給設(shè)計(jì)模式起個名字,，卻可以加快伙伴間的交流,。不過必須警惕一個陷阱，那就是為模式而模式,。強(qiáng)迫代碼去使用某個模式是很危險的,。
- P106 避免失誤
失敗的經(jīng)驗(yàn)比成功的經(jīng)驗(yàn)重要。如今網(wǎng)游開發(fā)尤甚,。我們的游戲能成功,，是因?yàn)槲覀冊谑『笪〗逃?xùn)，小心謹(jǐn)慎,。我們的代碼未必質(zhì)量高很多,，但是很多業(yè)內(nèi)同仁做出的東西吸取了許多人家成功的經(jīng)驗(yàn)卻失敗了，正是因?yàn)樗麄內(nèi)鄙賹κ〗逃?xùn)的學(xué)習(xí),。
- P111 自上而下和自下而上的設(shè)計(jì)方法
很多人都贊同自上而下的設(shè)計(jì)方法,，把問題逐步分解，再分而治之,。而我喜歡至下而上的設(shè)計(jì)方法。先把絕對要做的模塊做了,，再考慮怎么把他們搭起來,。但是我在實(shí)際操作的時候往往是，自下而上的做,，自上而下的思考,。書這里對兩種方法的優(yōu)缺點(diǎn)的總結(jié)非常精辟。我特別同意最后的結(jié)論，這兩種方法并不是互相排斥的——你會受益于二者的相互協(xié)作,。
- P114 開發(fā)人員不把原型代碼當(dāng)作可以拋棄的代碼,。
這個問題很嚴(yán)重，我多次看到過了,。做原型真的是一個好方法,，但一定要明白，有些代碼寫出來就是為了以后扔掉的,。
- P118 使用數(shù)碼相機(jī)
設(shè)計(jì)文檔不一定要詳細(xì)的寫成規(guī)范的文檔,，重要的是我們做了設(shè)計(jì)并保留下來，而不是寫出漂亮的文檔（去蒙投資,？）數(shù)碼相機(jī)似乎是一個好東西,，這樣可以把草稿紙上的亂涂亂畫保留下來。我一直覺得鉛筆是設(shè)計(jì)師最好的伙伴,。開會的白板也是,，雖然現(xiàn)在已經(jīng)有電子化的白板，但是,，昂貴的東西不是所有開發(fā)人員都需要的,。
- P131 不要讓 ADT 依賴于儲存介質(zhì)
這點(diǎn)早就意識的到，類里面最好不要有 readfromfile ,， writetofile 這樣的方法,。但是為了方便，往往又會加上這些方法,。最終的結(jié)果是,，依賴文件帶來的不便總是比便利要多。同理,，依賴文件名也是不恰當(dāng)?shù)?。可悲的是,，有些錯誤犯一次往往不夠,。意識到這樣做的不好是很容易的，真正杜絕它是另一件事,。
- P143 在萬不得已時通過 private 繼承來實(shí)現(xiàn)“has a”的關(guān)系
private 繼承的主要原因是讓外層的類能夠訪問內(nèi)層被包含類的 protected 成員,。根據(jù)我自己的經(jīng)驗(yàn)，讓類有 protected 成員本身就不是一件好事,。我剛學(xué) C++ 的時候,，很多類都有大量的 protected ，但現(xiàn)在,，只剩下了 private 和 public ,。雖然偶有 protected ,，但是我相信，那些都是可以通過改良設(shè)計(jì)然后去掉的,。我不喜歡教條,，如果有教條說，不準(zhǔn)用 protected ,，我會很反感,。而實(shí)現(xiàn)上，我的感覺會排斥 protected 的使用,。
- P174 對于超過 200 行代碼的子程序來說,，沒有哪項(xiàng)研究發(fā)現(xiàn)它更夠降低成本和/或降低出錯率
這是個誰都懂的道理，但是錯誤我自己也犯過,。早幾年,，我為大話西游編寫了一個圖文混排的函數(shù)，可以在聊天或是其他屏幕文字中同時顯示不同的文字,，有不同的顏色,，狀態(tài)，效果,，還可以顯示動畫圖標(biāo),。當(dāng)時圖一時方便，還有一些效率原因,，我寫了一個幾百行的函數(shù),。再接下來的幾年里，我為這個函數(shù)多次頭痛過,，出過不只三次的 bug ,。直到在夢幻西游的項(xiàng)目里，這些模塊得到全部重寫才舒了一口氣,。長達(dá)千行的子程序我也在一些地方見過,，那也是非常可怕的,。并非所有程序員可以真正認(rèn)識到這樣做的可怕程度吧,。
- P176 使用 C++ 中的 const 關(guān)鍵字來定義輸入?yún)?shù)
能夠正確充分的使用 const 是合格的 c++ 程序員評判標(biāo)準(zhǔn)之一。
- P176 不要把子程序的參數(shù)用做工作變量
不要因?yàn)橄氘?dāng)然的效率因素使用輸入?yún)?shù)做工作變量,，編譯器會幫你優(yōu)化的,。如果這樣做，至少在我們公司內(nèi)部的 codeview 上是要被嚴(yán)重警告的,。
- P210 確認(rèn)留在代碼中的錯誤消息是友好的
讀這段的時候想到同事給我講的一個故事：他以前的同事因?yàn)榍贸雠K話被開掉了,，起因是他的老板（也是一個程序員）在調(diào)試代碼的時候被某個模塊的出錯信息罵了一通 :D
- P220 通過偽代碼編程過程創(chuàng)建子程序
并非所有的代碼編寫前都要有偽代碼的。更古老一點(diǎn)的編程方法里,，要求編寫程序前先畫框圖。這種方法我也學(xué)習(xí)過，但始終不覺得自然,。偽代碼如果也有條條框框,，說不定我也不會去用。但是,，實(shí)現(xiàn)復(fù)雜算法時,，這種方法依舊被我使用的最多。一個附帶的好處就是,，先有了注釋,，然后刪掉多余的；而不是先有代碼,，再加上注釋,。
- P238 數(shù)據(jù)認(rèn)知測試
哈哈，我得了 28 分（或者是 27.5) ,，而且沒有被作者的陷阱框住,。
- P240 隱式變量聲明對于任何一種語言來說都是最具危險性的特性之一
早年，我們用 Lua 的第 4 版寫腳本,，結(jié)果在這個問題上吃過幾次大苦頭,。好在 lua 在第 5 版后增加了 metatable 可以有辦法避免這個問題。那就是給 _G 定義一個 __newindex 的 method ,。例子在 lua 包里的 test 目錄下可以找到,，![[External Link]](http://image4.360doc.com/DownloadImg/2009/3/19/111235_2859447_1.gif "在新窗口中打開") pil 里也應(yīng)該有提到。
- P244 Rob Pike 建議使用 0xDEADBEEF 這一常量來填充內(nèi)存,，因?yàn)樵谡{(diào)試器里很容易識別它,。
其實(shí)還可以用 0xBADF00D 也很有趣，可惜是 7 個字母,。有個朋友用這個做網(wǎng)名,，我還蹭過一頓飯。:D
- P246 盡可能縮短變量的存活時間
這是一個淺顯但實(shí)用的道理,。p248 里還提到,，全局變量的存活時間最長，就憑這一點(diǎn),，我們也應(yīng)該避免使用,。使用全局變量和不使用，是關(guān)易寫代碼和易讀代碼的區(qū)別,；也是“方便性”和“智力可管理性”的理念區(qū)別,。這一節(jié)還有個被量化的概念，變量的跨度,。把一個臨時變量重復(fù)使用,，在增加了存活時間的同時也增加了其跨度,，所以出現(xiàn)了很糟糕的味道。這一點(diǎn)在 P255 又談了一次,。
- P253 綁定時間
一般說來,，變量的綁定時間越晚，靈活性越好,。這里的關(guān)于綁定時間的總結(jié)很不錯,。分別為：
- 編碼時綁定 (使用 magic number)
- 編譯時綁定 (使用命名常量)
- 加載時綁定 (讀注冊表，配置文件等)
- 對象實(shí)例化時綁定 (創(chuàng)建對象時讀入)
- 即時 (每次操作時讀入)
綁定越晚,，在增加靈活性的同時,，也增加了耦合度。
- P256 避免讓代碼具有隱含含義
這里有個例子其實(shí)我曾經(jīng)也類似的干過,，變量 pageCount 在非負(fù)的時候表示已打印紙張的數(shù)量,，否則，-1 表示有錯誤發(fā)生,。這在技術(shù)領(lǐng)域里被稱為“混合耦合”是應(yīng)該避免的,。pageCount 客串了一個 boolean 類型。如果真的想節(jié)省一個變量的空間的話,，我覺得使用 union 可能能好些,。
- union {
- int pageCount;
- struct {
- unsigned int unused:31;
- unsigned int pageError:1;
- };
- };
- 或許這也不是個更好的方案。
- P298 在程序生命期中盡早決定國際化/本地化策略
關(guān)于這個問題,，我們吃過的苦頭足夠說明問題,。另外，MS 倡導(dǎo)的 _T() 宏不一定是一個優(yōu)秀的方案,。如果要支持 unicode ,，UTF-8 是個不錯的選擇，雖然不總是最好的,。UTF-8 表示漢字時 50% 超出的儲存空間好好考慮一下,。
- P301 更安全的做法是使用 strlcpy() 或 strcpy_s()
很高興看到這句話是在譯注里列出，可見譯者是用了心的,。類似的譯注,，我在侯杰的譯書中見過。不過 strlcpy 和 strncpy 的行為還是有區(qū)別的,，strcpy 往往可以簡單的用 strncpy 取代,，但是 strlcpy 卻沒有這個效果。不過我也傾向于用 strlcpy ,，它同 strcpy 一樣的高效,，而且的確也更安全。strncpy 在參數(shù)為 NULL 時會出錯,。
- P305 把 enum 的第一個元素留做非法值
這是這本書讀到現(xiàn)在碰到的第一個以前沒想過的技巧,。一直我都是把非法值定義成最后一個 enum 值,，或者定義成一個很大的特殊數(shù)字。書這里的道理很充分,，因?yàn)橐恍]有合理初始化的變量往往是 0 ,，把 0 作為非法值更容易捕捉到錯誤。
- P309 Monty Python 為 20 世紀(jì) 60 年代英國經(jīng)典電視連續(xù)劇,，python 語言由此得名。
還是譯注,，很有趣 :) 我以前并不知道 python 的名字是怎么來的,。
- p329 簡化復(fù)雜的指針表達(dá)式
上學(xué)的時候，我經(jīng)常寫 p->q->r->s.data 這種表達(dá)式,，當(dāng)我工作后,，被這種表達(dá)式坑過幾次后，用額外的指針變量來提高代碼清晰度(p327) 同樣成了我的信條,。另外 p329 介紹的畫一個圖的方法也是被經(jīng)常使用,。
- P330 分配一片保留的內(nèi)存后備區(qū)域
用樣來保證程序崩潰的緊急處理所需要的內(nèi)存是個簡潔的方法。
- P364 濫用case語言
把不同的控制結(jié)構(gòu)混在一起用的確是非常糟糕的習(xí)慣,。不過有時候的確可以帶來高一些的效率,。我們可以不用它，但是不能讀不懂它,。這讓我想起上次去跟同事一起出差,，在火車上他談到的一個例子：
- int n = (count + 3) / 4;
- switch (count % 4) {
- case 0: do {
- dosomething0();
- case 1:
- dosomething1();
- case 2:
- dosomething2();
- case 3:
- dosomething3();
- }
- while (--n>0);
- }
P374 在 while 循環(huán)更適用的時候，不要使用 for 循環(huán)
- 道理早就明白,，可是就是老不遵守 :( 我想還是因?yàn)閼小?
- P376 一個循環(huán)只做一件事情
我在自己的書中談性能時也提到過這一點(diǎn),，其實(shí)，合并幾件事情在一個循環(huán)做不一定可以得到更高的性能,。
- P377 避免出現(xiàn)依賴循環(huán)下標(biāo)最終取值的代碼
還是一個早就明白的道理,，但是錯誤一犯再犯。
- P384 for 循環(huán)變量的作用域
VC 中的語義跟 C++ 標(biāo)準(zhǔn)定義的不一樣,。MS 推薦一種解決方法：
-
#define for if (0); else for
- P397 如果為我工作的程序員用遞歸去計(jì)算階乘,，那么我寧愿換人
說的好。如果我?guī)У男峦略?C 語言里用遞歸計(jì)算斐波納契數(shù)列,，估計(jì)我也會教育一下的,。
- P399 讓代碼不包含 goto 并不是目的，而只是結(jié)果,，把目標(biāo)集中在消除 goto 上面是于事無益的,。
p408 還有一句，如果程序員知道存在替換方案,，并且也愿意為使用 goto 辯解,，那么用 goto 也無妨,。
- P408 軟件開發(fā)這一領(lǐng)域是在限制程序員對代碼的使用中得到發(fā)展的
這里舉的例子，允許根據(jù)行數(shù)或者標(biāo)號調(diào)用子程序,，是我早年用 basic 時夢寐以求的,。不過那個時候 basic 過于簡陋，期待這種功能是迫不得已,。實(shí)在不行的時候還要自己擴(kuò)展 basic 解釋器,。
- P429 最后是去找一個好的方案而且同時避免引發(fā)災(zāi)難，而不要試圖去尋找最佳的方案,。
我想補(bǔ)充,，如果你知道一種更好的方案但是不能完全避免災(zāi)難的時候，請注釋這種更好的方案,。
- P442 這項(xiàng)建議（在等于表達(dá)式中的常數(shù)寫在前面以避免把 == 錯誤的敲成 = 的問題）與按造數(shù)軸排列的建議相沖突,。我個人偏向于使用數(shù)軸排序法，讓編譯器來告訴我有沒有無意寫出的賦值語句,。
我也不希望把常數(shù)寫在前面,，但老說不清楚原因。
- 關(guān)于剩下的 400 頁：代碼大全》的確是本好書,，雖然厚達(dá)九百頁,，但是卻沒有什么廢話。讀書筆記只做到這里,，云風(fēng)也意尤未盡的看完了書的最后一頁,。缺少后一半的讀書筆記并不是說書的后半本不及前半本精彩。相反,，我認(rèn)為后面的某些章節(jié)對我的啟發(fā)更大,。只是，后半本書是我花了半個月時間,，每天臨睡前躺在床上看完的,。早上起來，已經(jīng)懶的在機(jī)器上敲下什么文字了,。喜歡這篇讀書筆記的同學(xué),，推薦去買一本《代碼大全》耐心的閱讀全部。
|
