※ 引述《LPH66 (-858993460)》之铭言： : 於是 !!T1 + 2 * !! T2 + 4 * !! Carry 这个算式 : 将三件事 (T1 != 0, T2 != 0, Carry != 0) 编码成一个整数 : 若三者都为 0 则它会算出二进位的 000 = 十进位 0 : 若只有 T1 非 0 则它会算出二进位的 001 = 十进位 1 : 若只有 T2 非 0 010 = 十进位 2 : 若只有 Carry 非 0 100 = 十进位 4 : 等等 : 这样就能以 switch 一次判断三个条件的真假 : 你可以注意到这个 switch 里的 case 有注解写说这是什麽情况 : 就是这麽来的 : → final01:程式设计师有必要那麽懒吗 211.21.157.199 03/10 12:19 通常我们会遇到一些沟通及思考上的懒人,直接看到结果去推原因. 像这件事情,专案管理者指派一个task给程式设计者,程式设计者知道requirement需求, 然後经过unknown process,产生了product即程式维护的结果. function task(requirement) { ...(unknown processes) return product; } 在专案管理者眼中,明明很清楚程式设计者只知道requirement和product,但是在 专案管理者脑中会自动补完那段unknown process,最後会变成他们的一句话: "如果我是老板,看到这样的程式码我会fire掉写这程式码的人." 但是实际上不是. 在程式设计者的眼中,有可能是经过这样的程序: 1. 我要做一个函数是将 t1, t2, carry 对应到 0~7, 分别代表八种情况. 2. 用 if-else 写一次, "靠!一层又一层的好丑." 3. 分成一段又一段的if, "这样子程式拉那麽长,看了後面忘了前面." 4. 使用8421编码 (即本文所讲的方法), "感觉应该不错." 这些 1 2 3 4 点程序的数量和内容不一定是这个样子,而是像人性一样变化多端. 总而言之,一段看起来精细的程式码,是经过多次整修之後的结果, 而不是一开始程式设计者只打算用这种复杂的构思方式写程式. 有时候我们看到一些看不懂的程式,应该先看自己有没有能力从陌生的程式码理出头续. 如果没办法看懂,究竟是要检讨自己阅读能力有限,还是检讨别人的程式码有毛病呢? 这就看各人的修养及容忍力. (我个人认为,从程式码静态结果去反推程式设计者的思考方式正确与否,是蠢蛋在 做的事. 程式码是反覆修改而得到最後的状态,并不代表这个写程式的人心里全都 是怎麽想的.) 关於程式合作方面,有人说程式最好写得好维护. if-else很好维护啊,逻辑顺序清楚, 但是恰好就因为有*逻辑顺序*,所以如果维护者没办法抓得到那个逻辑顺序,程式 瞬间就变成难以维护的东西. 很多人应该都碰过程序式的程式,从头到尾漏漏长, 每一段都好简单,但是要抓错发生在什麽位置就要从头到尾看每个变数的状态, 那样子叫做好维护吗? 相较来看,像本文这种 !!T1 + 2 * !! T2 + 4 * !! Carry ===> int 程式短小,值域明确,只差语法上面比较不好读的这种情况,表面上看起来不好维护, 实际上如果这一段程式有算错,要修改时,UnitTest自动测试程式做下去,各种测试资料 刷个几次,如果正确通过就完成,维护的时间可能短少很多. 本人是很惧怕那种看到程式稍微难读就该该叫的合作者,遇到那种人,程式难维护或 容易维护都没关系,最麻烦的就是程式写复杂一点点就吵不完. 沟通上问题比较麻烦. (说穿了数学差就承认嘛,嫌程式复杂是哪一招...) 抱歉一点点题外的牢骚. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.160.108.73 ※ 编辑: yauhh 来自: 218.160.108.73 (03/10 13:28)