一些常見任務的C代碼可以在項目中共享並保存以供將來使用。但我應該如何保留它們？在.c或.h？我注意到C頭文件（.h）通常只包含函數聲明，而不是定義，這似乎是推薦的做法。C頭文件的使用和代碼重用
將聲明和定義在mycode.h，這樣我就可以簡單地#include "myheader."並留下所有作業的編譯器。
將聲明在mycode.h和定義在mycode.c。可能符合公約？但我必須每次編譯和鏈接mycode.c。
什麼是最佳實踐？有什麼建議麼？
編輯：
大家都說＃2是更好的做法。但是我怎樣才能告訴編譯器定義/實現（.c/.o/.so？）駐留在頭文件中？正如我簡單地#include並使用printf（...）;？
最好的做法是第二個選項，因爲它不僅簡單，而且也對增強和maintaince
方案2是最好的做法。爲什麼選項1不好？如果標題中存在定義，則這些定義的範圍爲全局。它剝離了軟件的模塊化。限制變量的範圍是一種很好的做法，因爲軟件單元耦合度較低，因此軟件更容易維護。
如果使用make系統，只需要編譯已更改的.c文件。
使庫（的.so或.dll - 你的毒藥），然後鏈接到它
頭文件，然後會告訴編譯器什麼是提供給它
我會修改你的答案，更換靜態鏈接」請問這是否正常 – manuell
能be.lib？ - 但是，嘿，如果你想靜態或動態（做動態的聲音更性感？），然後選擇一個或另一個 –
雖然不經常使用，我已經看到了在.h中包含大量代碼的項目。如果您確信代碼只能用於一個項目中，我認爲將代碼放在標題中並不存在重大缺陷，儘管這種情況非常罕見。
我會建議把它放在一個.c中，但爲了能夠將它作爲一個單獨的模塊或共享庫進行編譯。這將緩解其他開發人員的工作並提高可重用性。
這實際上取決於您的項目之間共享的文件數量。
如果你有文件的大互聯集合通常最好創建一個動態庫或靜態庫和靜態或動態鏈接應用程序（S）針對。
一般 - 堅持＃2
頭文件是窗口到外面的世界，這就是，代碼做什麼（接口）。 它是怎麼做的（實施細節）是其他模塊和項目真的不在乎的東西。
假設你擁有一家雜貨店，和你的客戶會要求您提供蘋果的一打。你： - 檢查顯示屏上是否有蘋果。 - 如果不是，請到後面的房間去取一些。 - 如果你用完了蘋果，告訴客戶它，並下令恢復股票。
然而，客戶只是希望他的蘋果打;並不在乎他的訂單細節。
您可能會看到聲明和定義位於同一個.h文件的情況。在使用C++模板時，就我而言這是強制性的。在其餘的情況下，它會假設額外的編譯時間，因爲這些定義將被編譯，儘管自上一次構建以來沒有更改過。
感謝，但有什麼辦法告訴編譯器在哪裏！定義/實施（？.C /的.o /的.so）在頭文件駐留**正如我只是'的#include
stdio.h中的呢？例如屬於C標準庫，包含這個庫是「預先知道」的文件，因此你不必將它們添加到您的項目。你必須用他們各自的.h文件來調用。 – Manex
如果您要使用第三方庫，您可能會看到成對的.h文件和二進制輸出文件（.lib，.dll）。通過將您的項目引用到這些輸出文件中，並使用提供的.h文件（這些文件提供了訪問功能的方法），您可以使用這些庫。不同之處在於您無法訪問實現細節（爲了封裝，構建方便，知識產權或所有這些細節...） – Manex
使用第二個選項...或者創建庫，無論它是動態的（.so）還是靜態的（.a）都取決於您.. 是的，動態庫大小與靜態庫相比較少。 所以第二種選擇是最好的。通過「動態或 - 「（你的毒藥。所以或.dll）」
選項中只有1 h文件需要編譯那麼最後一個是不是邏輯論證.... –