过度追求代码短小优雅有什么害处？

本人目前是尚是一枚acmer,方向web开发, 同时python,php,golang,js等语言都有所涉猎.

由于接触python较早.深受python拿来主义的影响.平时写过很多小项目,但几乎每个项目都引用了很多开源项目,而且代码长度都极其的短.

如最近的一个某某管理系统.整个前台只有一个静态页面,数据全部使用json格式传输,用angularJs渲染界面.主体angularJS+Bootstrap+jQuery然后还有几个Bootstrap和jQuery小插件.服务端是php+mysql+Memcache,同时设计服务端时甚至想过升级nosql数据库和使用golang替换php.这样的阵容估计比某些大型企业的管理系统还大.自己都觉得有点小题大做.
然后完成整个前台增删查改,统计了一下自己的代码发现代码量还不到1000行(除去引用的库代码).估计全部完成撑死1500行.

别人一个页面模板代码就1000行..经常听到某某学长一个星期开发出某某网站,然后上万行代码.那个惭愧

然后自己写的一些数据抓取的脚本什么的.代码量也小得可怕,撑死200行.但是却引用了一大堆不知名的开源项目.而且像下面这样的代码到处都是

userList = [ i.split(":") for i in open("user.txt").read().split("\n") if len(i) >0]

回复内容：

其实嘛，在微软，如果有一个人用了牛逼的算法，或者什么奇技淫巧，反正很高大上的把一个东西搞了出来，但是别人看不懂，这个时候我们会被要求开讲座和写教程，来教会同事们，不然方案很可能就会被否决。

所以说只要这个代码的作者也可以时刻做到这样的话，害处大概不大吧。

凡事都讲个“度”，你自己都说“过度”了。
最大的坏处就是可读性差了吧。

ps：最后那个例子我倒觉得还好，不算很过分，还不至于影响别人理解。

问题中多处提到"过度", 提问者恐怕心中大概都有自己的答案了.

追求代码短小, 可以通过不同的方法, 只要是选择能提高可读性的方法, 其实未尝不可. 例如题目中的代码, 其实还没做到短小优雅, 这样做可以更短小易读(这行还不到80个字符), 通常是更推荐的做法.

<span class="n">userList</span> <span class="o">=</span> <span class="p">[</span><span class="n">line</span><span class="o">.</span><span class="n">split</span><span class="p">(</span><span class="s">":"</span><span class="p">)</span> <span class="k">for</span> <span class="n">line</span> <span class="ow">in</span> <span class="nb">open</span><span class="p">(</span><span class="s">"user.txt"</span><span class="p">)</span> <span class="k">if</span> <span class="n">line</span><span class="p">]</span>

浪费时间在别人制定的规则系统里“优化”自己的行为

while (i >= x || j >= x) { x = (i % x == 0 && j % x == 0) ? (y = x) + 1 : x + 1; } 曾经写着玩儿的一个求最大公约数的方法，现在连我自个儿都看不明白了，可见代码的易读性是多么的重要！
——成心文的微博|新浪微博

如果产品开发要求快速迭代，在满足时间和性能需求的情况下使用开源库，又能保证代码精简，我认为这本身无可厚非。

从我的经验来看，可能有以下几点需要注意的：

1、公司的法务部门是否允许使用这些开源库

开源协议那么多，也许某个库的协议会造成公司产品的法律纠纷，这种事情应该尽量避免

2、快乐的使用各种第三方库的时候，也请注意优化问题

除了性能优化之后，还有一些奇怪的问题需要优化。

前两天看豌豆荚的一个视频 “豌豆荚：成长的烦恼”，里面提到随着代码的膨胀，遇到了一个dex的函数上限65536的瓶颈，不得不反复合并函数。
其中提到对第三方库的选择时，要注意不要为了使用一个功能，却引入不必要的包袱。

Python我不熟，不确定会不会也有类似的坑，仅供参考吧。

3、最后一点，却是最重要的一点，越精简的代码，越要有充分的注释


一行糅杂了多个库函数的NB代码，当时写出来可能爽的一笔，心中暗骂自己真TMD的是天才。
过两天再看发现完全搞不懂当初为啥这么干了。

这种事儿我干过，不止一次。

比方说长长的正则表达式，注释里面写上匹配目标的范例，绝对没错。
在你需要更换平台时，很可能需要改写正则表达式的写法，参考范例放在那儿，写单元测试也好搞。
但是有一次我忘了……

所以，充分的注释是必要的，不仅为别人，更为自己。 对于Python
建议看看PEP 8 -- Style Guide for Python Code

我初学的时候也喜欢用各种「trick」来让代码看起来「碉堡了」
但是其实易读性太差了, 其他人看的时候都会一边看一边骂... 某牛人说过：“代码先是给人看的，再是给机器执行的”。
某古人说过：“物无美恶，物极必反”。

所以追求是好事，但过分追求，不免带到极端。
人生苦短，追求什么得想清楚。：） 大型项目开发时可维护性和可扩展性很重要..短小有时候可能会和可扩展性有矛盾。过度引用, 尤其不知名的开源项目可能会和可维护性有矛盾...优雅嘛...如何定义优雅...?

P.s.: Go + AngularJs是很正常的搭配...没有特别觉得这是一个overkill.... 短小的代码主要看一个问题：对后续程序员的理解是否增加了难度。

如果理解容易的话，这没有问题。

如果不容易理解的话，那尽量还是写多一点代码，方便容易理解为主。

实际的开发工程中，代码往往是会经过多个程序员的手，容易理解很重要，过度追求代码短小是不提倡的。

这个度的把握要靠经验的，根据不同项目不同团队而不同。

上面的代码有一个小问题： 你用了变量i， 如果用line可能更好理解。