|
编码迷局
迷惑 C
从互联网上的各种混乱C 语言竞赛中学习，追随大师们的脚步。
追求极致
总是追求用最迷惑的方式来做普通的任务。例如，要用数组来把整数转换为相应的字符串，可以这么做：
char *p; switch (n) { case 1: p = "one"; if (0) case 2: p = "two"; if (0) case 3: p = "three"; printf("%s", p); break; }
一致性的小淘气
当你需要一个字符常量的时候，可以用多种不同格式： ‘ ‘, 32, 0×20, 040。在C或Java里10和010是不同的数（0开头的表示16进制），你也可以充分利用这个特性。
造型
把所有数据都以 void * 形式传递，然后再造型为合适的结构。不用结构而是通过位移字节数来造型也很好玩。
嵌套 Switch
Switch 里边还有 Switch，这种嵌套方式是人类大脑难以**的。
利用隐式转化
牢记编程语言中所有的隐式转化细节。充分利用它们。数组的索引要用浮点变量，循环计数器用字符，对数字执行字符串函数调用。不管怎么说，所有这些操作都是合法的，它们无非是让源代码更简洁而已。任何尝试理解它们的维护者都会对你感激不尽，因为他们必须阅读和学习整个关于隐式数据类型转化的章节，而这个章节很可能是他们来维护你的代码之前完全忽略了的。
分号！
在所有语法允许的地方都加上分号，例如：
if(a); else; { int d; d = c; } ;
使用八进制数
把八进制数混到十进制数列表里，就像这样：
array = new int [] { 111, 120, 013, 121, };
嵌套
尽可能深地嵌套。优秀的程序员能在一行代码里写10层()，在一个方法里写20层{}。
C数组
C编译器会把 myArray 转换成 *(myArray + i)，它等同于 *(i + myArray) 也等同于 i[myArray]。 高手都知道怎么用好这个招。可以用下面的函数来产生索引，这样就把代码搞乱了：
int myfunc(int q, int p) { return p%q; } ... myfunc(6291, 8)[Array];
遗憾的是，这一招只能在本地C类里用，Java 还不行。
放长线钓大鱼
一行代码里堆的东西越多越好。这样可以省下临时变量的开销，去掉换行和空格还可以缩短源文件大小。记住，要去掉运算符两边的空格。优秀的程序员总是能突破某些编辑器对于255个字符行宽的限制。
异常
我这里要向你传授一个编程领域里鲜为人知的秘诀。异常是个讨厌的东西。良好的代码永远不会出错，所以异常实际上是不必要的。不要把时间浪费在这上面。子类异常是给那些知道自己代码会出错的低能儿用的。在整个应用里，你只用在main()里放一个try/catch，里边直接调用 System.exit()就行了。在每个方法头要贴上标准的抛出集合定义，到底会不会抛出异常你就不用管了。
使用异常的时机
在非异常条件下才要使用异常。比如终止循环就可以用 ArrayIndexOutOfBoundsException。还可以从异常里的方法返回标准的结果。
狂热奔放地使用线程
如题。
测试
在程序里留些bug，让后继的维护代码的程序员能做点有意思的事。精心设计的bug是无迹可寻的，而且谁也不知道它啥时候会冒出来。要做到这一点，最简单的办法的就是不要测试代码。
永不测试
永远不要测试负责处理错误、当机或操作系故障的任何代码。反正这些代码永远也不会执行，只会拖累你的测试。还有，你怎么可能测试处理磁盘错误、文件读取错误、操作系统崩溃这些类型的事件呢？为啥你要用特别不稳定的计算机或者用测试脚手架来模拟这样的环境？现代化的硬件永远不会崩溃，谁还愿意写一些仅仅用于测试的代码？这一点也不好玩。如果用户抱怨，你就怪到操作系统或者硬件头上。他们永远不会知道真相的。
永远不要做性能测试
嘿，如果软件运行不够快，只要告诉客户买个更快的机器就行了。如果你真的做了性能测试，你可能会发现一个瓶颈，这会导致修改算法，然后导致整个产品要重新设计。谁想要这种结果？而且，在客户那边发现性能问题意味着你可以免费到外地旅游。你只要备好护*和最新照片就行了。
永远不要写任何测试用例
永远不要做代码覆盖率或路径覆盖率测试。自动化测试是给那些窝囊废用的。搞清楚哪些特性占到你的例程使用率的90%，然后把90%的测试用在这些路径上。毕竟说起来，这种方法可能只测试到了大约你代码的60%，这样你就节省了40%的测试工作。这能帮助你赶上项目后端的进度。等到有人发现所有这些漂亮的“市场特性”不能正常工作的时候，你早就跑路了。一些有名的大软件公司就是这样测试代码的，所以你也应该这样做。如果因为某种原因你还没走，那就接着看下一节。
测试是给懦夫用的
勇敢的程序员会跳过这个步骤。太多程序员害怕他们的老板，害怕丢掉工作，害怕客户的投诉邮件，害怕遭到起诉。这种恐惧心理麻痹了行动，降低了生产率。有科学研究成果表明，取消测试阶段意味着经理有把握能提前确定交付时间，这对于规划流程显然是有利的。消除了恐惧心理，创新和实验之花就随之绽放。程序员的角色是生产代码，调试工作完全可以由技术支持和遗留代码维护组通力合作来进行。
如果我们对自己的编程能力有充分信心，那么测试就没有必要了。如果我们逻辑地看待这个问题，随便一个傻瓜都能认识到测试根本都不是为了解决技术问题，相反，它是一种感性的信心问题。针对这种缺乏信心的问题，更有效的解决办法就是完全取消测试，送我们的程序员去参加自信心培训课程。毕竟说起来，如果我们选择做测试，那么我们就要测试每个程序的变更，但其实我们只需要送程序员去一次建立自信的培训课就行了。很显然这么做的成本收益是相当可观的。
编程语言的选择
计算机语言正在逐步进化，变得更加傻瓜化。使用最新的语言是不人性的。尽可能**使用你会用的最老的语言，先考虑用穿孔纸带，不行就用汇编，再不行用FORTRAN 或者 COBOL，再不行就用C 还有 BASIC，实在不行再用 C++。
FORTRAN
用 FORTRAN 写所有的代码。如果老板问你为啥，你可以回答说有很多它非常有用的库，你用了可以节约时间。不过，用 FORTRAN 写出可维护代码的概率是0，所以，要达到不可维护代码编程指南里的要求就容易多了。
用 ASM
把所有的通用工具函数都转成汇编程序。
用 QBASIC
所有重要的库函数都要用 QBASIC 写，然后再写个汇编的封包程序来处理 large 到 medium 的内存模型映射。
内联汇编
在你的代码里混杂一些内联的汇编程序，这样很好玩。这年头几乎没人懂汇编程序了。只要放几行汇编代码就能让维护代码的程序员望而却步。
宏汇编调用C
如果你有个汇编模块被C调用，那就尽可能经常从汇编模块再去调用C，即使只是出于微不足道的用途，另外要充分利用 goto, bcc 和其他炫目的汇编秘籍。
与他人共事之道
老板才是真行家
如果你的老板认为他20年的 FORTRAN 编程经验对于现代软件开发具有很高的指导价值，你务必严格采纳他的所有建议。投桃报李，你的老板也会信任你。这会对你的职业发展有利。你还会从他那里学到很多搞乱程序代码的新方法。
颠覆技术支持
确保代码中到处是bug的有效方法是永远不要让维护代码的程序员知道它们。这需要颠覆技术支持工作。永远不接电话。使用自动语音答复“感谢拨打技术支持热线。需要人工服务请按1，或在嘀声后留言。”，请求帮助的电子邮件必须忽略，不要给它分配服务追踪号。对任何问题的标准答复是“我估计你的账户被锁定了，有权限帮你恢复的人现在不在。”
沉默是金
永远不要对下一个危机保持警觉。如果你预见到某个问题可能会在一个固定时间爆发，摧毁西半球的全部生命，不要公开讨论它。不要告诉朋友、同事或其他你认识的有本事的人。在任何情况下都不要发表任何可能暗示到这种新的威胁的内容。只发送一篇正常优先级的、语焉不详的备忘录给管理层，保护自己免遭秋后算账。如果可能的话，把这篇稀里糊涂的信息作为另外一个更紧急的业务问题的附件。这样就可以心安理得地休息了，你知道将来你被强制提前退休之后一段时间，他们又会求着你回来，并给你对数级增长的时薪！
每月一书俱乐部
加入一个计算机每月一书俱乐部。选择那些看上去忙着写书不可能有时间真的去写代码的作者。去书店里找一些有很多图表但是没有代码例子的书。浏览一下这些书，从中学会一些迂腐拗口的术语，用它们就能唬住那些自以为是的维护代码的程序员。你的代码肯定会给他留下深刻印象。如果人们连你写的术语都理解不了，他们一定会认为你非常聪明，你的算法非常深奥。不要在你的算法说明里作任何朴素的类比。
自立门户
你一直想写系统级的代码。现在机会来了。忽略标准库， 编写你自己的标准，这将会是你简历中的一个亮点。
推出你自己的 BNF 范式
总是用你自创的、独一无二的、无文档的BNF范式记录你的命令语法。永远不要提供一套带注解的例子（合法命令和非法命令之类）来解释你的语法体系。那样会显得完全缺乏学术严谨性。确保没有明显的方式来区分终结符和中间符号。永远不要用字体、颜色、大小写和其他任何视觉提示帮助读者分辨它们。在你的 BNF 范式用和命令语言本身完全一样的标点符号，这样读者就永远无法分清一段 (…), [...], {…} 或 “…” 到底是你在命令行里真正输入的，还是想提示在你的BNF 范式里哪个语法元素是必需的、可重复的、或可选的。不管怎么样，如果他们太笨，搞不清你的BNF 范式的变化，就没资格使用你的程序。
推出你自己的内存分配
地球人儿都知道，调试动态存储是复杂和费时的。与其逐个类去确认它没有内存溢出，还不如自创一套存储分配机制呢。其实它无非是从一大片内存中 malloc 一块空间而已。用不着释放内存，让用户定期重启动系统，这样不就清除了堆么。重启之后系统需要追踪的就那么一点东西，比起解决所有的内存泄露简单得不知道到哪里去了！而且，只要用户记得定期重启系统，他们也永远不会遇到堆空间不足的问题。一旦系统被部署，你很难想象他们还能改变这个策略。
| 
楼主
标题置顶
标题高亮
多谢多谢，
