好像不自觉就写了难以维护的代码 ...

代码

重构

维护

79 条回复 • 2014-12-04 04:31:21 +08:00

1

bcxx

2014-11-29 21:10:57 +08:00

把最后的三目改简单点会舒服点吧= =

2

Sunyanzi

OP

2014-11-29 21:15:50 +08:00

@bcxx 最后那个小三元的逻辑是两个 if 分支的三个 return ...

既然都是 return 为何还要写三次而不是把结果都写在一起 ..?

3

GTim

2014-11-29 21:17:09 +08:00

赞..用sublime text久了自然而然就会写的像这样..

4

kmvan

2014-11-29 21:19:31 +08:00 via Android

类方法多少和资源占用没必然联系吧。如果内存多占用1kb，大家都看明白，那值

5

evlos

2014-11-29 21:19:35 +08:00 via iPhone

团队合作的时候少用点三元运算符吧

6

herozzm

2014-11-29 21:20:35 +08:00

代码量不大，挺清晰的啊，还能接受吧

7

evlos

2014-11-29 21:21:04 +08:00 via iPhone

用三元运算符：可读性 -5 效率 +1

8

kankana

2014-11-29 21:22:13 +08:00

换是我拆成几个小方法, 没必要那么夸张多弄几个类...

9

haiyang416

2014-11-29 21:22:40 +08:00 via Android

不至于看不懂吧，
但是代码读起来不“舒畅”，就像大段中文没有断句的感觉。

10

GTim

2014-11-29 21:23:22 +08:00

@kmvan 如果不上缓存，多一个文件就要多一次io.

11

bcxx

2014-11-29 21:26:06 +08:00

@Sunyanzi 我对这种多层逻辑的做法一般都是 fast fail：那些会先不符合的部分就先 return false 掉，接下来一个再判断另外一部分的逻辑（对应你注释里面的 "then take remote ..."）。这样感觉 **快速阅读** 起来的时候思路会清晰一点。

当然你认为它们逻辑上是应该在一块所以要放到几个三目里也行…… 不同人有不同习惯~

12

Sunyanzi

OP

2014-11-29 21:35:44 +08:00

@kmvan 在没有额外缓存的情况下 ... 文件加载吃 io ... 类声明吃内存 ...

@evlos 为何我觉得三元比 if block 更具可读性 ..?

比如这段程序里的 $notify_id 和最后的 return ...

用三元就相当于我在明确声明之后的代码只会为这个变量赋值和决定函数返回值 ...

而且习惯我的这种思路之后再看到我用 if block 时就会潜意识的加个小心看我有什么其他操作 ...

这样难道不是很好 ..?

@kankana 对于我来说只有可复用的部分我会抽到单独的方法中 ...

我不太能接受为了语意声明函数 ... 而且也不能接受一个方法在全局中只被另外的一个地方调用 ...

@haiyang416 我在努力使用缩进增加这种断句感了 ... 看来 ... 作用还是不大呀 ...

13

freefcw

2014-11-29 21:38:20 +08:00

代码太长了，你确定一个函数的功能就是一个？

三目运算符是我极不愿意用的，至少三目运算符只在短小的时候我才会考虑，这么长一个完全就不具备可读性

目测这个函数至少要拆分到3个函数才具备一目了然性

1. $payinfo提取为类A应该是明智的做法
2. notify_id应该放到类A里面
3. 签名payinfo应该也要放到类A里面

最后那个正则，你自己去读一下看看一次能读懂意思么

14

RIcter

2014-11-29 21:41:54 +08:00

话说 PHP 有什么编码标准吗..
窝一直按照 PEP8 的标准来写的（Python 大法好

然后看菊苣们写代码都要 if ( ! ( owo ) ) 感觉..
求教 www

15

freefcw

2014-11-29 21:44:39 +08:00

一行代码之有一个功能，三秒钟能看懂这一行做了什么
一个函数只有一个功能，不混杂要处理更低一层逻辑的代码

16

bcxx

2014-11-29 21:46:34 +08:00

1

@RIcter psr

17

bcxx

2014-11-29 21:48:11 +08:00

1

@Sunyanzi

> 习惯我的这种思路之后...

不能赞同这种做法=,= 明明是应该只有代码在没有人在的嘛……所以我一直很不喜欢写 author 信息。真要找渣代码元凶就上 git blame 啊

18

ruoyu0088

2014-11-29 21:49:36 +08:00

7

写代码的人是先有逻辑，然后按照逻辑写代码，因此怎么写都很顺。但是不了解逻辑就读代码的人，是按照代码思考逻辑，那么这段代码就是属于很难读的那种了。

19

lightening

2014-11-29 21:50:09 +08:00

1

"谁如果觉得我这段代码晦涩只能说明他自己 php 水平不过关 ..."
可是你这段代码的作用是希望更多人看懂，还是考核对方的 php 水平呢？

我不懂 php，不过我觉得三目运算符嵌套很不好。而且你的代码看上去就一坨，感觉就很难懂。

20

rqrq

2014-11-29 21:55:17 +08:00

不需要拆分吧，处理下三元，对了用那样的方法给$sign赋值也容易看走眼。

21

freefcw

2014-11-29 22:00:09 +08:00

p.s.

我不知道为什么你要把两个功能放一起。。notify和return，应该分开才清晰

总而言之，你这个函数里面做了太多的事情，直接意义上会认为你是在验证回调，但是还分了两种回调，还去请求了？反正$this->$method[$type]('sign')这种代码。。请问怎么读懂这行代码？还不如一个if else来得清晰易懂
获取notify_id这种低层级的代码。。。
还有一个ssl_request的调用，加上一大堆的字符串拼接。。。这些和verfiy_callback有什么直接关系么？？

最后在说一下

"谁如果觉得我这段代码晦涩只能说明他自己 php 水平不过关 ..."

楼主是在玩代码混乱大赛么。。代码除了运行外，更重要也是读的，据说统计结果是90%的时间是在读代码，不知道楼主写这段代码的时候反复读了多少次，想了多少道，纠结了多久代码要怎么改，不过我想既然发出来问，就意味着知道里面肯定有问题

22

jedihy

2014-11-29 22:01:29 +08:00

@evlos 效率会有变化？

23

xuwenmang

2014-11-29 22:04:22 +08:00

没看懂。。。

24

aveline

2014-11-29 22:28:05 +08:00

大脑内置三元操作符的鸭子你好 ...

25

kankana

2014-11-29 22:28:32 +08:00

@Sunyanzi 哈哈,还真是各有各的怪癖

你"不能接受一个方法在全局中只被另外的一个地方调用"

我是不能接受太长的一行和方法 :)

26

xing393939

2014-11-29 22:32:16 +08:00 via iPhone

1

个人觉得现在的开发可以轻性能，重维护和关注业务层。有想提升性能的想法不如多考虑大体方案上的改进以及分布式和可扩展性。

27

miniwade514

2014-11-29 22:33:03 +08:00

2

看来也是觉得三目运算符用多了的人比较多。。

我个人写代码的时候也喜欢（习惯）把“当时”感觉简单的逻辑用三目运算符写，但是需要回头改的时候还是得打散、理顺，从维护角度来看没有省事儿。在团队里写代码的时候基本上不用三目运算符了，用的话也会避免较复杂的操作，只做一些简单的数值处理。

而且我觉得即使 if 后面只有一个 return 的操作，也应该写 {}，换行。因为谁知道什么时候又不止 return 一个操作了呢？多写一对 {} 占不了多少时间，所以还是看个人习惯的~

一点个人想法 :)

28

shiny

2014-11-29 22:36:41 +08:00

写 php 的时间越是久，越是觉得大智若愚，大巧若拙。

29

nine

2014-11-29 22:50:44 +08:00

三元不要嵌套啊！
其实嵌套也可以啊！但你里面的拼接那么长的字符串是要闹哪样啊！
放到外面声明一个变量啊！字符串拼接一定要用 "{$foo} foo bar {#bar}"的方式啊！不然怎么读啊！
三元的层次要分好啊！怎么能允许2个“:”在同一行啊！
其实三元嵌套放在一行也可以的啊，你要把那一坨字符串声明成变量啊，其实就是你拼接字符串的问题啊，你这么拼怎么读啊！，剩下的三元嵌套即使放到一行里面也没人说你啊！

为什么看起来像一坨？其实完全就是你拼接字符串搞得鬼啊！
受不鸟了啊！啊！啊！啊！啊！
十万个冷笑话吐槽星人放元槽弹了啊！

最后一行改成这样舒服多了

30

nine

2014-11-29 22:53:03 +08:00

不好意思，拼接字符串符号习惯写成 + 了

31

kmvan

2014-11-29 22:58:27 +08:00

@GTim 如果不上缓存，多一个文件就要多一次io.
加个缓存就完事的事情。

@Sunyanzi 在没有额外缓存的情况下 ... 文件加载吃 io ... 类声明吃内存 ...
为了省内存而把逻辑弄得一团糟，除了自己，团队其他人都看不懂，那有啥意义。

32

RemRain

2014-11-29 23:00:46 +08:00

2

```在没有额外缓存的情况下 ... 文件加载吃 io ... 类声明吃内存 ...```
线上都得开 APC 或者 opcache 跑吧，我以前也担心过这个问题，后来发现随意加一个 Guzzle、monolog 之类的 lib 进来，立马多上百个文件，就再也不操作 class 多的问题了。

大多数人的阅读习惯都是从上而下的，如果既要从上而下，又要从左到右的读，就很累了。三目运算是个好东西，问题是广大人民往往会在其中塞入很多很多东西，导致不堪入目，还是少用的好。

另外
```
$param = http_build_query($parameter);
$param = urldecode($param);
$paramMd5 = md5($param);
```
才是断行，往一行代码中插入换行真的不能算断行~

话说，每行代码，包括定义变量、ksort 数组都加上注释，真的有必要么

33

xylophone21

2014-11-29 23:03:11 +08:00

没有人觉得函数前的注释全是废话吗？
看起来貌似有文档，可提供的信息基本上为0.

34

PP

2014-11-29 23:08:48 +08:00

如何编写无法维护的代码 http://blog.jobbole.com/80241/

35

mcfog

2014-11-29 23:09:18 +08:00

开发何苦为难开发……

36

Cofyc

2014-11-29 23:14:28 +08:00

@freefcw +1

37

pubby

2014-11-29 23:24:38 +08:00 via Android

读起来好费脑细胞

@xing393939 赞同，这个场景没必要死磕性能，不是天猫双十一而且跑PHP的谁不用些opcache呢

38

jianghu52

2014-11-29 23:26:40 +08:00

1

第一个三元我读了两遍终于能确定楼主的意思。
第二个三元我读了4遍，才敢说能猜到楼主的意思。
php代码写了500行左右的菜鸟的感觉。

39

123123

2014-11-29 23:29:10 +08:00

除了最后的 return，感觉还好

40

nooper

2014-11-29 23:30:37 +08:00

php 代码还写了一坨。。。。

41

yaoyen0002

2014-11-29 23:38:59 +08:00

很简单的逻辑用三元，长的还是不要用三元了，和if else相比，我需要努力的去找?:在那里，再加上你这里面还有函数调用，就更绕了。。
让人一眼看过去，能读懂80%，或者大致掌握你的思路的和代码才是便于理解维护的，这样一个大长句子。。不好

42

wdd2007

2014-11-29 23:39:50 +08:00

讨厌三元嵌套。

43

sophymax

2014-11-29 23:58:51 +08:00

一段代码贴出来想挑毛病肯定是能挑的出来的 , php的我不好评判 , php的水平有限 , 所以我是绝对不会去把这些代码拆成好几个类的(不会用php的类是主要原因,虽然和其他语言的类差不多但也懒得去学,觉得鸡肋) , 但之前见过Java的项目经常往前jump七八次跳到一个地方 , 竟然是个接口 , 还要找不知道在哪的初始化类 , 那个初始化还是加载一个不知道在哪的xml来初始化的 ,人家还弄了个类专门去各种路径寻找这个xml , 那种情况才真的是想骂娘 , 难道Java项目(非安卓)都是这样 ? 周围人都还说这代码很有水平 , 除了过度封装过度解耦我真没看出这种代码有啥水平,不知道是我水平低还是说他们在拍领导的马屁 , 现在感觉Java程序员离开xml就没办法活一样 , 拿过来个json数据他们也会让对方转换成xml再给他

44

crs0910

2014-11-30 00:00:28 +08:00

感谢，才知道三元还可以嵌套着用。。。
以后写 js 会努力用上的。

45

evlos

2014-11-30 00:06:40 +08:00

@jedihy 效率应该没有，我搞错了

46

jamiesun

2014-11-30 00:11:44 +08:00

果然是垃圾代码。

47

PrideChung

2014-11-30 00:11:47 +08:00

我觉得三元运算符是可以提高可读性以及让代码更简练的，但前提是不能嵌套着用

48

ryd994

2014-11-30 00:11:57 +08:00 via Android

三元嵌套也是醉了

49

yuxing1171

2014-11-30 00:50:32 +08:00

三元都被你用烂了!
return a ? b ? true : false : false;
可以简单的写成 return a && b;

50

mkeith

2014-11-30 00:50:34 +08:00

三目运算就不要换行加嵌套了吧

51

otakustay

2014-11-30 00:50:51 +08:00

6

我觉得楼主的几个坚持基本都是反可读性的……

> 为何我觉得三元比 if block 更具可读性 ..?

老实说觉得三元比if可读的人可能不少，但在三元中的任何一元带有多段逻辑而依旧认为提升可读性的就不多了，不信你做个调查试试……觉得嵌套三元比if可读的人会更少，不信还是做个调查试试

> 而且习惯我的这种思路之后再看到我用 if block 时就会潜意识的加个小心看我有什么其他操作 ...

所谓可读性，不是让别人像你一样思考，而是让大部分人按照大部分人的思考逻辑可以看懂

> 我不太能接受为了语意声明函数 ... 而且也不能接受一个方法在全局中只被另外的一个地方调用 ...

基于语义拆解函数（哪怕只被调用一次）是非常常规的一种提高可读性的做法，本质是将逻辑拆解成树型，而每一个函数只体现树的一层而不再深入，通过函数的调用形成整棵树的全局，便于理清逻辑关联（只看树的整体节点分布）和逻辑细节（看每个节点的内容）

> 我在努力使用缩进增加这种断句感了 ... 看来 ... 作用还是不大呀 ...

缩进增加可读是对的，但个人认为你缩进错了……三元要可读性高就应该在?和:前后换行并缩进，而不是把一堆字符串拼接缩在一起，后面跟了个? true: false，差点就找不到?和:啊

---

对于所谓增加class会加重内存和IO，不熟悉PHP不作评论，但是真的要假设不开opcache跑程序吗？

---

最后还是那句，要让代码可（被大多数人）读，就不要有自己的“坚持”和“不能接受”，无数的“坚持”和“不能接受”可能造就一个鲁讯，但我承认我看不懂鲁讯的文章，也没有去习惯鲁讯的思路的那份追求，哪怕我是春上村树

今天你坚持嵌套三元可读性高，明天你的团队就可能来一位和你同工种同级别的坚持switch可读性高的同事，你们是想撕逼一场吗

可读性这事上，没有牛逼与不牛逼，团队里一半人认为你不行，你就是不行。比如jQuery曾经的源码就非常牛逼但各种可读性差，后来他们改了- -

52

bombless

2014-11-30 01:30:55 +08:00

改不了不至于= =
不过嵌套的三目运算、强行让人看另一个方法什么的倒是够呛，哈哈

53

xcv58

2014-11-30 01:35:25 +08:00 via Smartisan T1

一堆魔术字符串，一个 && 就能解决的强行用三目运算。然后硬要说可读性？

54

branchzero

2014-11-30 04:26:08 +08:00

三目嵌套看着好晕= =
注释可有可无的说

55

thonatos

2014-11-30 06:40:55 +08:00

好像我写的还是很有格式的....

56

xmbaozi

2014-11-30 09:44:02 +08:00 via Android

醉了。lz果然老道。不过我还是觉得应该多拆行。另外很赞同49l

57

maddot

2014-11-30 09:52:36 +08:00

这样的代码，你自己过一月再回去看，估计都很费劲吧，连返回语句都在多处拼接字符串，真是一坨shit,不是读不读得读的问题，我根本就不会去读

58

efi

2014-11-30 09:59:03 +08:00

你们厂php没有规定代码风格么？还是说php无论怎么写都会变成一坨屎？

59

GTim

2014-11-30 10:07:02 +08:00

楼上的几位，最后怎么都变成最后一个三目运算符了..楼主一开始的初衷是把多个文件合并成一个文件。

60

jarlyyn

2014-11-30 11:05:55 +08:00

多建几个子函数。
每个需要注释的都放子函数内。
主函数子负责逻辑判断和体现流程。我一般都是这么做的。
不然你这代码做单元测试都没法做。

61

jarlyyn

2014-11-30 11:09:44 +08:00

支付宝的php代码我也重构过。
不过处于业务需要，是建了支付类的子类，然后所有功能尽可能的拆细了，主函数控制流程。
需要测试只要测各个子函数，需要检查流程看主函数就可以了。
你的代码风格是我所不喜的风格。
还有访问的url等常量我个人会放在文件头的一个变量/类属性里。方便以后调整。直接写代码里不容易调试，还容易让修改的人该错。

62

jarlyyn

2014-11-30 11:13:42 +08:00

还有从我的角度来说。代码更重要的是可读，可修改，可测试。
可读是知道整体逻辑，知道流程，而非怎么去实现。实现与否不该靠读出来的。
可修改是只任何需要修改的地方应该只牵涉到几处代码片段，而非整个代码。
可测试是和可读对应的。
逻辑，功能靠读。
实现不应该靠读，靠测试。
所有走一个逻辑没问题，跑一次单元测试没问题，那就ok了。

63

qaulau

2014-11-30 11:14:37 +08:00 via Android

三元运算里套三元运算，关键是连个括号都没有，这样的代码也就自己看着爽

64

loryyang

2014-11-30 11:19:30 +08:00

我觉得写的不好，首先所有if后面都要加{}，这是代码规范。然后一行代码不可以写这么长，要想办法做简化。静态的string用常量来表示，比如你的正则表达式。好处：一是方便复用和后续修改，二是人肉看更直观（因为有命名）。然后函数嵌套的太多了，宁可多设置几个变量或者多抽几个函数，不要把代码揉成一坨。不要说是否看得懂，看到这种代码，没几个愿意认真看的。

65

scys

2014-11-30 11:21:31 +08:00

1

挺好懂的，逻辑堆在那里罢了。
你同事比较懒，如果一眼看不懂，基本他们才懒得动。
就这么个理解，嗯嗯。

66

zwdsix

2014-11-30 11:31:08 +08:00

镇压吧，多爽。

67

lizheming

2014-11-30 11:39:55 +08:00

说不上难懂，不过一眼能看出来估计有压力吧...反正那个三元混搭Style我是看了两遍，主要是在找:在哪里，2333...不过怎么说呢，我可是鸭子大大的脑残粉，怎么能说鸭子大大写的代码不好呢！恩哼！

68

cnallenzhao

2014-11-30 12:04:16 +08:00

我是觉得$tmp 这种命名方法太反人类了

69

abcfyk

2014-11-30 12:23:02 +08:00

2

最后一个嵌套的三元运算看得我都醉了。。

http_build_query($parameter)) .
$this->_config['key']
拼接字符串时从.号处换行真的好吗。我书读的少。不要骗我。。
还有函数变量里用三元运算符。。还是嵌套的三元运算符真的好吗。。
看来LZ还没意识到其他同事反应的不是你封装的问题，而是代码风格的问题。
写代码就像写文章一样诚然你可以在一句话里把一整篇文章打完并用了很好的修辞手法和换行但是如果你没有适当的介绍和断句那么不就是像我现在一样咯里吧嗦的打了这么多字但是看起来还是很费力而且不讨好吗要知道好的代码就像一篇好文章能如沐春风般在悄无声息间让读者不知不觉便顺着你的思路如
同文思如泉涌般喷薄而出不由得抚掌而叹好文好文虽文字浅显却立意深刻意味深长的缘故啊。

70

AlanZhang

2014-11-30 12:30:25 +08:00

没做过支付宝的，但是看这一段代码，还是蛮意大利面条的，分得不够细，代码自身不大expressive.

71

Gn

2014-11-30 12:32:24 +08:00

楼主写得很妙啊。2333

你是我见过的唯一一个用三元运算符最后还返回true和false的人才啊。2333

return a;
非得写成 return a ? true : false;

return a && b;
非得写成 return a ? b ? true : false : false;

人家看不懂一定是因为你没有拆分成几个类然后用你华丽的技法加载嘛。

72

waytoexploreOO

2014-11-30 13:09:15 +08:00 via Android

qq

73

zhengkai

2014-11-30 13:23:54 +08:00

这代码不能再糟了，你要在我们组可能会被石刑……

不过对于年轻人这是必由之路，多写代码来提升自己吧（我们公司有个岁数很大的老员工，写 PHP 的，动不动就写 $foo == false 或者 $foo == "" 或者 if (is_array($a) && count($a) == 0) 这类东西……）

以及要看《代码大全》《程序员修炼之道》

74

crossmaya

2014-11-30 14:32:51 +08:00

楼主是来现英文注释的吗。。。

75

Sunyanzi

OP

2014-12-01 15:56:46 +08:00

吓 ... 周末睡了一天没上网 ... 回来就发现这么高的楼 ...

我在 V2 有史以来的第一高楼居然是挂自己得到的 ... 还真是悲伤呢 ...

答读者问时间 ... 恐不能面面俱到 ... 如有不周还请体谅则个 ...

@RIcter php 有 PSR ... 不过我讨厌那个规范 ...

@freefcw 谢回复 ... 我想想从哪里说起 ...

关于为什么把 notify 和 return 放在一起 ...

只是因为这两种方式都是支付宝的回调 ... 而且数据结构类似 ...

以及我其实没太看懂你的修改建议 ... 求详细 ...

至于一行代码只有一个功能这点我认同 ... 而且我的那段代码里也没有犯多义性错误 ...

一个函数只有一个功能什么的 ... 也就是函数重载是不能用的咯 ...

@kankana 谢回复 ... 我也不能接受太长的一行其实 ...

在我那张图上最右边有条细细的线有注意到吗 ... 对我而言那条线就是不可逾越的存在 ...

很莫名其妙的坚持我知道 ... 奇怪的强迫症 ...

所以我会很注意不使用过深的语法结构 ... 以及单行超长的时候用换行缩进将其拆分 ...

@miniwade514 谢回复 ... 既然在写的「当时」觉得简单 ...

在不扩充功能的前提下它一定就是简单的 ... 那么为什么还要将其重构掉呢 ..?

换言之 ... 为什么要让代码适应团队而不是让团队适应代码 ..?

@nine 谢回复 ... 我也知道这样会更清晰 ... 但这样就超长啦 ...

参考我上面说不越线的那一条嗯 ...

@kmvan 谢回复 ... 虽然看起来代码一大坨 ... 但我的逻辑有一团糟吗 ...

求脱开代码来解释逻辑糟在哪里 ...

@xylophone21 @RemRain @crossmaya 谢回复 ... 关于注释的问题我一并说了吧 ...

我这人在写代码的时候习惯于写些文法不通的废话 ... 也就是代码里的注释部分 ...

这并不是为了提供什么信息 ... 只是我在思考下一步的时候给手上找点事做而已 ...

不让我写这些废话的话我是无法把代码写下去的 ... 就像转笔一样只是一个辅助动作 ...

@yuxing1171 @Gn 谢回复 ... 我之所以没用 && 也是为了提高可读性 ... 但好像适得其反了 ..?

@otakustay 谢回复 ... 受教 ...

@cnallenzhao 谢回复 ... $tmp 那个确实是偷懒了 ...

但只在单行可用 ... 定义和使用都在一行 ... 下一行就被销毁了 ...

@abcfyk 谢回复 ... 嗯我喜欢这个回复风格 ... 真的 ...

@zhengkai 谢回复 ... 为啥会被石刑啦 ... 地球就是绕着太阳转的哼！

76

freefcw

2014-12-01 17:23:46 +08:00

2

@Sunyanzi

我真的不知道怎么说了，很有耐心的给你分析了很多

对于两种返回方式分割成两个函数调用，这样代码会更可读（感觉上）。数据结构类似不是放一块的原因。不过是两个不同的方式而已，你就要弄的这么复杂，让人要停下来前后看才能看懂

payinfo提取为一个类，这样可以把很多相关的功能放到一起，不是更清晰明了？
$notify_id这一行拆分，难道不应该放到payinfo这个类里面去？明显是和payinfo有关的信息

unset这是蛋疼事情，如果后续变动怎么办？

ksort的功能应该和md5这个都放到payinfo的一个方法里面么

return里面到底执行了多少个功能呢？典型应该拆分的地方，一句话做了这么多事情
那个http 请求，不应该是一个单独的函数的功能么
那个签名，如果后续变了怎么办？

唉，不能不感慨下，能写出这样的代码的人，我只能说脑容量一定很大，或者是我等智力有所不及……不然怎么会花这么多人绞尽脑汁分析这段代码呢

77

freefcw

2014-12-01 17:57:59 +08:00

@Sunyanzi

最近在读《代码整洁之道》，其实正好符合你的这个问题，建议对照着核对一下

78

beaaar

2014-12-01 22:14:38 +08:00

@mcfog +1

79

Sunyanzi

OP

2014-12-04 04:31:21 +08:00

1

嘛 ... 虽然可能已经没人看了 ... 但我还是说一下最新进展好了 ...

顶楼的代码我自以为在「可读性」与「简洁性」之间找到了一个平衡点 ... 看来做得还是不够 ...

于是我又把它重构掉了 ... 去掉了所有三元嵌套只为增加可读性 ...

顶楼的代码就是孤本了 ... 挂在这里做个纪念好啦 ...