前段時間寫了不少代碼，不是隨手寫練習，而是一整個項目做下來的，于是就有了一些以前不曾有的心得，不過都來源于《有效C++》之類的書，只不過自己親身經歷之后體會更深刻一點。
1 ?一個類的成員變量實在太多的時候，對這些變量進行分類包裝吧。我寫過一個類，里面有很多數據成員，多得在編寫該類的功能函數的時候常常要去頭文件回顧各個變量的名稱和意義。后來覺得太難受，就將這些變量分類，一個類別是關于運動變量的，一個類別是關于攝像機運動的，還有一個類別是物理規則方面的，也就是說我在該類內部聲明了3個struct，并實例化了他們。
個人的感覺是，對于煩雜的東西進行適當的歸類，便于管理。
2? Log類。一個項目是要時刻注意將一些運行信息進行輸出的，那些信息對調試具有不可取代的意義，透明化的意義就在于此。事實上，當編寫的項目涉及到第三方庫的時候，很有可能依靠帶斷點的debug運行已經極為耗時，所以LogOut必要的信息是有益的，不要吝嗇代碼。
3? Exception類。如果你所依賴的庫沒有提供該類，那么在你的項目中自己寫一個，因為一般說來，std::exception并沒有提供你想要的東西。不要討論Exception所帶來的開銷，這里是C++，而異常所帶來的手感，勝過返回值10倍，而邏輯上也清晰得多。
4? 雜七雜八的東西都放到類初始化成員列表里不是什么好事。初始化成員列表是講究順序性的，可是類在實現的時候成員變量是一個逐步添加的過程，東西多了，就會亂了，初始化列表里的順序也就對不上了。
一般來說，只有那種需要拷貝構造函數初始化的變量，才放到初始化列表里。
5? 成員變量的初始值賦值。成員變量很多的話，如何在它們初始化的時候傳遞變量呢？構造函數是初始化的最好選擇。但是，一個擁有十幾個參數的構造函數嗎？又或者在類完成構造之后，通過set函數來設置？由此帶來的接口龐大，還有修改失控問題卻不能忽視。
在構造函數中傳遞一個文件名吧，然后該類負責從文件中讀取各個成員變量的初始值。我是比較傾向于這個方式的，其實類內很多變量都是規則性變量，通過從外部流中讀取，那么只要編譯一次，就可以得到不同的結果了，何樂而不為呢。
6? 盡量不使用protected。這里是說一個類層次設計的，作為基類，可以理解為子類的抽象，不過更多的時候，這種抽象對于我來說只是一個概念的問題，毫無意義。設計基類的真正原因，是接口通用，還有代碼復用，這在我看過的某些代碼里面都是如此的，抽象的意義讓人覺得很困惑，但是一想到是代碼復用，也就霍然開朗。
基類用public給出接口，用private給出變量，也許你會問，如果子類要用這些變量怎么辦？那么好吧，先說protected后會怎么樣吧?；惖某蓡T變量的使用權遺留給了子類，可惜我并不喜歡那些基類的成員變量，為什么？因為在我的經驗中，基類遺留下的變量都是相當龐大的，甚至有好幾個層次的基類，那些變量，經歷了一段時間之后，你還能對他們的名稱和意義爛熟于心嗎？我反正是糊涂的，反而在子類添加的變量最明白不過。
那么如果一定要用基類的變量怎么辦？你用那個變量只不過要實現某些功能，那么把那個功能的實現做在基類的一個函數就好了，函數總比變量來的明白。
事實上，我并不能很肯定本條規則，因為有的變量真的是不把使用權遺留下去是不行的啊。不過盡量少用protected是沒錯的吧。
7? 盡量少在一個封閉的函數內成對的進行動態內存分配和釋放，這種情況往往是想要一個不定長的臨時變量，如果可以，就用一個盡量長的buffer更好，否則你就要添加異常情況下刪除該變量的代碼。
我盡可能的只在構造函數和析構函數中應付動態內存。
8? 代碼越來越多，你能漸漸嗅出代碼冗余的味道了，重構吧，我常常是邊寫邊重構，而不是等所有東西都完成后才這樣做，因為那樣要改更多。