1. "以动手实践为荣, 以只看不练为耻"
俺写一个程序时间通常是这么分配的。
70% 的时间用来寻找和阅读现有代码, 如果找到了, 就不用自己写了。如果不够用或者不满意, 就把已有的实现看完, 稍加改进。或者在重构中抄进去, 天下程序一大抄嘛。
20% 的时间构思, 剩下 10% 的时间用来写代码。
这样我轻松违反了第一条, 我显然是, "以学习模仿为荣, 以埋头蛮干为耻"。
寻找源码, 追随源码, 模仿源码, 洞察源码, 成为别人的范例源码 ──── 这是我们的信条 (见《Plone Cookbook》)。
2. "以打印日志为荣, 以单步跟踪为耻"
如果不是数据恢复需要, 俺从来不打印日志。俺从来都是程序能跑起来就已经谢天谢地了。
我尽量把程序写成只要可能有问题就跑不起来或者马上挂掉的样子。比如我不处理异常 ──── 如果那真的是异常的话; 而且很少初始化变量 (比如写 __init__ 函数) ──── 如果不是马上就要用到的话。在应该是 AttributeError 的地方顺利通过的只可能是逻辑错误, 而不是对象完整性。没有就是没有, 除 XXX 以外既没有接口也没有 NotImplementedError。如果一个程序已经跑起来了才发现有问题, 那么日志对调试通常也不会有用处。
用户如果真需要日志, 请自己在顶层 traceback 所有异常写到日志, 或者重定向标准出错好了。
这违反了第二条, 我是 "以立即挂掉为荣, 以需要调试为耻" (下面还有一条关于测试的, 请参见本条)。
3. "以空格缩进为荣, 以制表缩进为耻"
没什么好说的, 制表缩进写了太多年, 已经习惯了。很遗憾空格缩进确实成为了标准, 这得归功于大把大把的 Windows IDE 初学者根本不知道自己其实是在用空格还是制表进行缩进, 并且写出成堆的只在该 IDE 下才能对齐的代码, 为此我们才不得不统一到空格缩进。要是统一成制表缩进, 那些家伙就根本无法对齐代码了。
──── 要做到对齐其实很容易, 你只要在需要代码缩进时用制表, 在需要对齐时用空格, 简单地说就是行头用制表, 后面用空格。
这条我也常常违反, 不过还是强烈推荐使用空格缩进, 毕竟这是标准 ──── 为了向下兼容和维护世界和平。
我是 "以 K&R 对齐为荣, 以 IDE 对歪为耻"。
4. "以模块复用为荣 , 以复制粘贴为耻"
"自从读了《重构》以后, 大家对重复代码都异常敏感起来; 重复代码的坏处太明显了, 为避免重复代码, 大家可谓绞尽脑汁; 最终基本形成这么一个事实: 只要没有重复代码 (当然还包括内存泄露), 这段代码就算高质量的代码, 就是可以被大家接受和敬仰的代码, 而代码的结构, 代码的可读性基本都被抛在脑后。
"《UNIX 编程艺术》教会我 '简单是美', 在写程序的过程中, 我都竭力让代码看起来尽可能简单一些, 程序的逻辑尽可能符合习惯并且清晰易懂。这一点和重构所宣称的思想并不冲突, 但重构实在太面向对象了, 过于教条, 甚至太死板了; 如果一切都按其所宣称的方法来消除重复, 那将是程序员的恶梦。
"其实我最关心的是, 和代码的整体结构相比, 消除重复代码的重要程度到底有多高? 如果为了消除重复代码而修改代码的结构, 使代码的结构变的比较复杂, 比较诡异, 比较难以理解, 难以维护, 这样做值得吗?
"个人觉得是, 重复代码可能是要消除的, 但不应该以代码结构复杂化、诡异化为代价; 如果重复一段代码可以使我程序的逻辑结构更清晰, 更易读, 更容易维护, 我宁愿重复。" ──── 魏中华(《为了消除重复代码》)
库是可复用的, 进程间通信和代码复制是零耦合的, 一切都很美好。而模块是从真空中产生的厚胶合层, 模块诞生的第一天, 是光鲜的, 是看起来可以重用一百年的。但不幸的是从第二天开始, 为了重用, 模块就一直被推翻、重写、取消和重建。程序结构越来越复杂和读不懂, 而且压根不会有第二个程序来重用该模块。这太讽刺了。
所以我是代码复制的粉丝, 大段大段的复制粘贴随处可见, 甚至专门编写程序来进行复制粘贴。我是 "以复制粘贴为荣, 以模块复用为耻"。
5. "以多态应用为荣 , 以分支判断为耻"
面向对象挺过时的, 在 Python 中时新 "ducktyping"。
所以我们, "以 ducktyping 为荣, 以面向对象为耻"。
基本上, 8荣铁律俺大部分都违反了。好了, 今天就说到这里吧, 我要回火星去了。