namejm

　　1、凡事都应有个度，要适可而止；
　　2、代码好不好，需要综合各方面的因素来考虑，而不应仅仅以长短论英雄；
　　3、代码短小精悍，确实是很多程序员毕生追求的化境，但这都是有前提条件的：只有在代码能准确解决问题，并且能高效率地完成工作的时候，再追求短小精悍才是有意义的；假设代码的执行结果是错误的，或者原本只需要两三分钟就可以解决的问题，你偏偏要绕个大大的弯路，用几条代码让机器跑上两三个小时才能解决，这个时候，短小精悍就失去了意义；
　　4、若是大型工程，确实需要对可读性、可扩展性有极高的要求；但是，如果事情很简单，只需要几行代码就可以解决的时候，若你还要给每条语句加上注释（考虑可读性）、费尽心思设计多个功能模块（方便日后扩展），则未免得不偿失；
　　5、三、四个for嵌套在一起，往往是为了有效利用动态产生的变量值，或者是为了避免生成临时文件，很多时候，若要把它们拆分开来，往往会浪费内存，或是要产生一些临时文件，这是高水平的程序员最不希望看到的情形；也许很多人会说，现在的内存动不动就是1G、2G，硬盘都是海量空间，几十M、上百M的内存占用，一两个的临时文件，我不在乎，可是，用户的系统资源并不只是为了运行你编写的那一两个程序吧？大家也不希望自己的杀毒软件一直在后台以90%的CPU占用在狂奔不已吧？我认为，最大限度地节约用户的系统资源，应是真正的程序员一直需要关心的问题，不能说有海量资源就可以任意浪费。
　　6、抛弃单纯追求最短小的想法是很正确的，但是，若要放弃代码的效率，则是不能原谅的——没有了效率的代码，一切都是空谈——你也不希望打开word程序需要半个小时的时间吧？你也不想做个加减法运算要让你等上十分钟吧？

namejm

　　其实选择算法的最主要目的是为了提高代码的执行效率，兼有提高程序通用性的功效，另有若干其他目的。有时候，多写一两行代码反而能显著提高代码的效率，这个时候，就不应该再去追求所谓的短小精悍。我不否认需要做必要的注释，也没有否认结构需要模块化，而是说，凡事都需要有个度，需要适可而止，并且，代码的好坏，并不是仅有长度这个唯一的衡量标准，而是需要综合考虑：为了执行效率，可以牺牲部分长度；若有了执行效率，则应考虑精简代码、增加代码可读性或代码的可扩展性；但是，如果注释满天飞、动不动就call调用模块，则未免太过浪费。