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荣铁律俺大部分都违反了。好了, 今天就说到这里吧,
我要回火星去了。
Python:编程“八荣八耻”,布布扣,bubuko.com
原文地址：http://www.cnblogs.com/gimmeangel/p/3754125.html
