先說明，這完全是我個人的意見，你可以（也許你真的會？）用別的方式來做。這會觸動到有關編碼風格的問題，而大家從來就沒有停止過在這個問題上的爭論。在這裡我只是給出我自己喜歡的做法（同時也給出這麼做的原因）：
i) 不要用乙個 header 檔案指向多個原始碼檔案（例外：程式包 的 header 檔案）。用乙個 header定義乙個原始碼檔案的方式 會更有效，也更容易查尋。否則改變乙個原始檔的結構（並且 它的 header 檔案）就必須重新編譯好幾個檔案。
ii) 如果可以的話，完全可以用超過乙個的 header 檔案來指向同 乙個原始碼檔案。有時將不可公開呼叫的函式原型，型別定義 等等，從它們的ｃ原始碼檔案中分離出來是非常有用的。使用一 個 header 檔案裝公開符號，用另乙個裝私人符號意味著如果 你改變了這個原始碼檔案的內部結構，你可以只是重新編譯它而 不需要重新編譯那些使用它的公開 header 檔案的其它的源文 件。
iii) 不要在多個 header 檔案中重複定義資訊。 如果需要， 在其中乙個 header 檔案裡 #include 另乙個，但 是不要重複輸入相同的 header 資訊兩次。原因是如果你以後改 變了這個資訊，你只需要把它改變一次，不用搜尋並改變另外一 個重複的資訊。
iv) 在每乙個原始碼檔案裡， #include 那些宣告了原始碼檔案中的符 號的所有 header 檔案。這樣一來，你在原始碼檔案和 header 檔案對某些函式做出的矛盾宣告可以比較容易的被編譯器發現。
開始某專案的研發c
以前自己做專案，都是快速實現功能，並沒有從設計模式或者頂層上去考慮，這樣的好處是進展快，原型出來的快，不足是擴充套件性 復用性不好。當初第乙個專案從學習c 到開發完成，用了三個月，在專案中學習能夠直奔主題，完全以功能的實現為主。這次的專案有乙個主負責人負責框架的編寫，但我覺得，有時候為了物件導向而物...
專案的總結
現在的專案快到結束了，該總結一下了。先寫下有關這個專案的一些標籤 三個月，乙個專案，還沒有做完，剛畢業，專案老套，技術落 後，同事缺乏交流，老闆不願重視，自己創造力不足，工作缺乏激情，做事條理不明，計畫嚴重滯後。剛畢業，進了一家好像很有前景的小公司，給了乙個 平台專案，從八月到十一月，三個月了，專案...
專案的總結
寫了兩天的課程設計，hibernate和stuts的結合，講一下自己的心得體會。以前這種感覺小，但是隨著慢慢的，這種感覺越來越強烈。乙個專案的實現這幾個步驟必不可少，否則，你的專案會出現你預想不到的問題。定義階段 一 需求分析，在寫專案時，要實現什麼首先要做需求分析，這個太重要了。二 可行性初步計畫...