編譯後的代碼可以刪嗎
1. c語言 編寫並運行了程序 產生的那些文件可以直接刪除嗎
當然可以了，c語言一般分為
.c 源文件 ，，存儲你寫的源代碼
編譯鏈接時一般會產生 .o 與 .exe
.o 就是object, 也就相當於windows下編譯的obj文件, 俗稱目標文件.
如在linux(UNIX) 下有這個文件就可以直接運行了
.exe windows下的可執行文件。
還有就是你進行文件操作的時候你自己利用操作文件的一些庫函數生成的文件，這個隨意，想刪就刪
2. knowngamelist.bin可以刪除嗎
不可以。bin是機器代碼，匯編語言編譯後的結果，所以不可以刪除。計算機（computer）俗稱電腦，是現代一種用於高速計算的電子計算機器，可以進行數值計算，又可以進行邏輯計算，還具有存儲記憶功能。
3. 使用VC++編輯C語言，生成*.exe文件後還有其他的好多亂文件可以刪除嗎
不影響的。
ilk是增量鏈接用的，自動生成；
opt看名字就是什麼優化的，自動生成；
dsw是工作空間吧，這個最好別刪，應該和我們現在用的vs2005 vs2008的項目文件sln一個作用;
plg 不知道，多半自動生成；
ncb 是自持自動完成的 intellisence的資料庫，刪除了也可以每次重新生成的；
dsp 不知道，多半自動生成；
obj 每個cpp編譯後生成一個相應的.obj，隨便刪，每次編譯會重新生成；
pch 預編譯頭文件， 也可以刪，刪了可以自動生成。
pdb 調試符號信息， 每次編譯鏈接生成；
idb 增量編譯用的，可生成；
手都打痛了，更詳細的你需要自己查msdn哈
4. 編完C程序後產生這么多文件，哪些可以刪掉，哪些要保留
這個不是編譯產生的，是你編輯代碼產生的，cpp是你的c++代碼，dsp，dsw是你的項目配置文件，ncb，opt什麼的都是和配置文件一起的，他們都是系統自動生成的，最好不要刪除，
你編譯產生的東西都在Debug里，你如果程序已經完成，也可以只要.cpp和debug里的.exe，一個是你的代碼，一個是成功的程序
5. 問個比較菜鳥的問題，src文件夾里的c++源碼編譯完後，這個文件夾可以刪掉嗎
不要刪除，以便以後修改、添加功能，或者移植，反正源文件佔用位元組數並不多，留著唄
6. IAR（for ARM）編譯產生的Obj文件可以刪除嗎
IAR（for ARM）編譯產生的Obj文件可以刪除
obj文件：
obj就是目標文件，是源程序經過編譯程序編譯後生成的，它不能直接執行，需要連接程序連接後才能生成可執行文件，這樣就能值行了。
這種目標文件一般是由機器代碼組成的，但也有例外，可以是自己定義的一些偽指令代碼，但這樣還需有專門的解釋程序對其進行解釋執行，連接程序是把目標代碼和它所使用的庫文件連接的程序。
打開obj文件可以使用UltraEdit或者autodesk maya軟體。
7. Linux下編譯安裝完成之後可以刪除安裝包嗎
Linux編譯安裝是編譯的源碼包，下載的源碼包在編譯完成後是可以刪除的。不過有一種情況就最好不要刪除了，有些源碼編譯時沒有安裝命令，就是說編譯後是直接運行源碼目錄裡面編譯好的二進制文件的，比如NetHack這個字元界面游戲就是這樣的，這種情況就不要刪除源碼目錄了。
8. java既然是先編譯，然後再執行編譯後的位元組碼文件，那是不是在編譯後就可以刪除源文件了
理論上是的，你第一步的 javac 將你的 .java 文件 編譯成 .class 位元組碼，之後 用 java 命令來運行 .class 文件。所以是可以刪掉源文件，但是一般程序都是要調試，調試後你的源文件就要變動，變動後就要重新編譯，所以一般沒人刪源文件，然後再重新寫一份。
9. xcode怎麼把編譯後的文件刪掉
因為它默認是隱藏的。
不過也可以改成還在項目目錄下生成build：
Xcode>>Preferences>>Locations>>Locations，Derived
Data的右側有個Advanced按鈕，點擊之後Build
Location改成Locations
Specified
by
Targets，點完成應該就可以了。
如果只是黃色嘆號的waring，我猜是你的項目啟用了
Svn或者git，文件被納入版本管理，而你手工刪掉文件而不是在Xcode里刪掉，則沒有從版本管理器中把文件刪掉，於是Xcode警告你版本管理工具沒找到這些文件了。如果是這樣，手工在命令行里敲下類似
svn
delete
<刪掉的文件名>
就行了。如果你有用
svn/git
客戶端則更方便。
10. 為什麼你可以大膽的刪除代碼呢
為什麼你可以大膽的刪除代碼呢？一般的話刪除代碼都有以下操作刪除代碼的最佳方法
這看起來似乎是明顯的，但我不這樣認為，因為開發者會使用大量的其他方式來刪除代碼。 刪除代碼的方式如下:
選擇編輯器中的代碼塊，單擊Backspace鍵，然後就完成了。
許多開發人員不願意刪除已經寫出的東西，他們想要保存大量的代碼塊以免再次用到。畢竟在編寫這些代碼塊的時候他們付出了很多工作，在調試的時候，它們可以工作。他們不想輕易的將它們扔掉。
這些開發者希望能夠保存他們老的代碼，所以他們使用一些方式將這些代碼失效：注釋掉，條件執行，或者僅僅是不再調用。
對於那些開發者，我想說「使用源（控制），Luke」，一個源代碼控制系統（例如 Git， Mercurial，或者 Subversion），意味著你永遠不需要擔心一些東西會永遠丟失。當你再次需要的時候你的儲存庫會給你提供哪些老代碼。
如果你沒有一個 源代碼控制系統(!?!?!)或者僅僅不想因為查找歷史記錄而被麻煩，那麼可以將代碼塊復制到一個單獨的文件區域，並保存。但是不要讓代碼留在他們不應該在的地方：在你的源代碼里。
What"s the big deal?
如果你有一塊不再需要的代碼，有一個需要刪除它而不是將它處於失效狀態的重大原因：減少噪音和不確定性。一個開發者會碰到一些最糟糕的敵人就是代碼中的噪音和不確定性，因為未來這些會導致代碼不能有效地運行。
失效狀態的代碼塊會引起不確定性。它會對其他開發者帶來疑惑：
§ 這個代碼過去為什麼是這個方式？
§ 為什麼新的方式更好？
§ 我們需要需要換回就的方式嗎？
§ 我們怎麼決定？
如果這些問題的答案需要人們知道，那麼寫一個注釋說明它。不要讓你的合作者猜測你的用意。
注釋掉代碼
注釋掉一行或者兩行（甚至20行）代碼是非常簡單的：
// OldWayStepOne(fooey);
// OldWayStepTwo(gooey);
NewWay(fooey, gooey);
這些注釋是糟糕的。注釋應該用於給讀者提供他們閱讀或者編寫代碼時需要的信息。注釋應該用於幫助未來將會使用這些代碼的開發人員。但是上面的注釋並沒有起到這些效果。事實上，它們的作用剛好相反。在將代碼從編譯中移除的同時，這些注釋增加了代碼的混亂、不確定性以及可質疑性。
後續的開發人員在查看這個代碼時會知道它老的運行方式，也會知道它新的運行方式，但是它們不知道為什麼老的運行方式依舊被保存著：
§ 可能新的方式只是一種實驗？如果是這種情況，那麼更好的代碼是什麼？最終版本的代碼是如何以及何時保存的？
§ 或許老的方式是更好的，但是有一些錯誤？如果是這樣的話，錯誤在哪裡？是老的方式中代碼有問題，還是我們調用時產生的問題？何時會被修復？
§ 或許設計以及改變了，所以老的方式不足以勝任？
任何的注釋掉的代碼都是一個潛在的問題「為什麼它仍然存在？保留一塊注釋掉的代碼是有理由的，比如當你知道很快就會恢復或者那些並不確定的修改。保存代碼通常沒問題，但是你需要表明為什麼保留，注釋是為了給別人看的，而注釋中的代碼並不能告訴任何人任何事情。
不要在沒有任何解釋的情況下注釋掉一段代碼 (in the comment).
下面這種方式會不會更好？:
// OldWay did a better job, but is too inefficient until MumbleFrabbitz
// is overhauled, so we"ll use NewWay until the M4 milestone.
// OldWayStepOne(fooey);
// OldWayStepTwo(gooey);
NewWay(fooey, gooey);
現在，誰知道是否MumbleFrabbitz真的會迎來M4里程碑式的大修？或許這種情況不會發生。但是沒關系，誰能知道未來會出現什麼情況？至少通過這種方式開發者會知道代碼被保存下來的原因。通過對改變的解釋以及老代碼存在的原因說明，開發者會知道他們可以安心的使用新方式，或者何時他們可以有到更好的解決方法。