编译后的代码可以删吗
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里程碑式的大修？或许这种情况不会发生。但是没关系，谁能知道未来会出现什么情况？至少通过这种方式开发者会知道代码被保存下来的原因。通过对改变的解释以及老代码存在的原因说明，开发者会知道他们可以安心的使用新方式，或者何时他们可以有到更好的解决方法。