看了吐槽同事代码风格的帖子来的，我的一点感想

[good1uck]

我觉得这事情最后还是谁经验多谁说的话有道理。
我刚入职那会也想着怎么把自己代码写漂亮，觉得又自由又有情怀，后来我们公司一个技术挺强的人看了我的代码只告诉我如果他需要给我改东西，他会无从下手。虽然是符合某种开发模式，特别规范，但是做某种小而快的东西，对接的时候就会有点麻烦，这个时候技术比我强的可能直接就推翻重写。
一开始学的时候不知道从哪些书上或知乎上看到要强调优雅，简洁。有时甚至会刻意避开 if else 用其他语法糖，就开始有点那种洁癖？觉得这样的才是好的？自己敲出某种很俗的代码就忍不住会去优化，行数越短越好，单方面给自己施加压力。

[good1uck]

我虽然只有 6 个月的工作经验你们不用听我
我看完帖子的评论后发现工龄越高的越能理解某种比较俗气的风格
但如果同样的问题问我之前的上司 CTO 兼股东的话，他大概率会说“那得看情况”

[good1uck]

*那种

[raaaaaar]

业务代码，和高质量有点冲突，很多时候可读性，健壮性，可维护性这些比性能要重要许多，单纯炫技肯定是不行的。

[oahebky]

（我写 Python ）
打开 Django 源码

和

打开基于 Django 实现的电商网站源码

...

[Mindjet]

你所指的那种书的确存在，如果看过《代码整洁之道》(豆瓣评分 8.6)，就应该理解类似的说法，短函数是非常重要的，作者欣赏的函数是那种只有 2~5 行的，最多不超过 20 行。

> 函数的第一规则是要短小。第二条规则是还要更短小。我无法证明这个断言。我给不出任何证实了小函数更好的研究结果。我能说的是，近 40 年来，我写过各种不同大小的函数。我写过令人憎恶的长达 3000 行的厌物，也写过许多 100 行到 300 行的函数，我还写过 20 行到 30 行的。经过漫长的试错，经验告诉我，函数就该小。(第 3 章 函数 - 3.1 短小)
> ...
> 这个程序中每个函数都只有两行、三行或四行长。每个函数都一目了然。每个函数都只说一件事。而且，每个函数都依序把你带到下一个函数。这就是函数应该达到的短小程度！(第 3 章 函数 - 3.1 短小)

当然你也能轻松找到很多反例，这只是经验之谈，这个经验既不清晰也不严格，但这的确是部分人的想法，而且还写在书里了。我很欣赏的是这个人能很清楚的看到这一点，不清楚后续有没有实证研究。

[Qiss]

很多其实和写作文一样，有的人喜欢用这种方式表达，不可能做到大家的表达都一样，只能做到相近吧，通俗易懂最好。

[dajj]

写功能要短小，好测试，好重用。 写业务要放在一起，好修改。

[yimity]

做事情 A 。
做事情 B 。
做事情 C 。
做事情 D 。
...
这是一个函数，可能有 400 行。
你把每个相对独立的逻辑抽出去就是 4 个函数每个函数 100 行。
读代码的时候，思路就是
做了事情 A 。
做了事情 B 。
做了事情 C 。
做了事情 D 。
完了插一脚，改一脚，都很好插很好改。
可以不炫技，平平淡淡，一读就懂才是最高境界。

[Cielsky]

鱼与熊掌不可兼得。
理论上要可读性高，可维护性好，实际上，今天加需求，明天改需求

[watzds]

@Mindjet 我工作几年，好多地方还是按照这本书的，但没必要完全照搬

[ungrown]

整洁、美观、优雅
这并不是工程追求的东西
当然工程并不排斥这些东西
工程只是不追求
如果追求这些会导致工程中其他的关键部分受阻
那这些追求就会靠边站
软件工程本质上甚至都不算是是在制造工具
因为工具已经在那儿了：能计算的机器
软件工程只是人在教工具怎么做事
也就是指挥而已
指挥就是讲话
讲话是技术也是艺术但归根结底还是技术
把话说清楚的情况下
尽可能提高讲话效率
所以让话变得简洁优雅当然是有意义的
但很多时候为了把一件事情说明白
最好的办法就是不厌其烦地从多个角度进行详细描述
这个时候如果强行格式化
倒不是说这话就没法讲了
但是无论是讲的人还是旁听的人都得遭罪

[tydl]

俗与雅相辅相成，喝着咖啡就大蒜，秋水长天一色。

[eGlhb2Jhb2Jhbw]

@good1uck #1 有追求是好事的，能保证自己的追求也是好事。不过我很不喜欢把别人贬的一文不值。在那个帖子中，大部分人都表达的是没有那么不堪，而不是他同事写的很好。

[Orenoid]

@Mindjet #5
短函数这个实践，我觉得有个两个前提是，要保证命名的可读性（或者要有足够的文档和注释），还有低耦合，否则反而可能会比较坑。
最近维护前同事的旧代码，他就很喜欢封装大量的函数，实现功能的时候一层一层构造一条很长的调用链。总的来讲，代码重复率确实很低，但那个代码真的维护得想死，他的很多命名根本说不清楚这个函数干了什么（因为是自己实现的，所以他可能觉得命名已经说得够清楚了），为了搞明白这一点，不得不进去函数读具体实现，进去又是一堆不明不白的函数调用。这样导致在阅读的时候，到处跳转，逻辑割裂严重，为了搞明白一个业务，甚至不得不深入到非常低层级的代码中去。如果是这种，我宁愿他写一些长点的函数，好歹有一个连贯可读的逻辑。
当然这个问题本质上不是短函数造成的，只是说在这个情境下，受代码上其他问题的拖累，反而降低了可读性和可维护性。

[maemual]

我觉得更多是逻辑拆分的清晰，而不是单纯追求代码短。如果把一个完整的逻辑愣是拆成若干个短函数，反而可能更麻烦。

[maddot]

@Orenoid
确实，函数名是最重要的东西，体现的是结构，函数的具体实现反而是细枝末节的东西，很多时候不值得讨论

[forbreak]

不写业务代码的时候，感觉卧槽我代码写的真好真优雅。加上了业务之后，感觉代码就是一坨屎。。。 很多地方不得不妥协。如果不想妥协，还想继续优雅，可能时间翻倍，架构推翻。为了一种小概率或者不发生概率，去把主要部分都重写一遍。。

[forbreak]

而且有时候，过渡追求代码优美，带来的后果就是。可读性变差，东一坨西一坨，并不容易阅读。还不如写成面条式。

[chocovon]

重复的东西写烦了或觉得将来很可能会写烦才做优化，否则怎么快乐怎么来

[clf]

其实说白了就是开发过程中懒得写注释。自己开发的工具类写上注释，别人可能看不懂的写上注释，所有业务逻辑相关的地方也写上注释。

就算别人不知道你这段代码的操作多么花里胡哨，那他也能根据注释去重新实现业务逻辑。

只要你的注释与文档足够清晰的描述了你自己定义的类或方法的逻辑，那么别人还看不懂可能就真的是水平问题了。