整理下目录,看了这个文件,幸好未删除。

以下是《write solid code》中的原文摘录。

1、How could I have prevented this bug?

2、How could I have automatically detected this bug?

3、If a programmer believes that a bug can simply "go away", or that fixing bugs "later" won't be harmful to the product, bugs will persist.

4、Having a good set of habits and attitudes is possibly the most important requirement for consistently writing bug-free code.

5、The developers can bring more knowledge and tools to reviewing and testing the code.

6、Finding and fixing bugs was Developments's responsibility.

7、If you find undefined behavior, either remove it from the design or include assertions to notify programmers when they use undefined behavior.
     Don't waste people's time. Document unclear assertions.

8、Once you've written a function, review it and ask yourself, "What am I assuming?" If you find an assumption, either assert that your assumption is always valid, or rewrite the code to remove the assumption. Also ask, "What is most likely to be wrong in this code, and how can I automatically detect the problem?" Strive to implement tests that catch bugs at the earliest possible moment.

9、The purpose of the debug version is to catch bugs, not to make the maximal use of memory.

10、You don't save time by fixing bugs late in the product cycle. In fact, you lose time because it's often harder to fix bugs in code you wrote a year ago than in code you wrote days ago;

11、Fixing bugs "as you go" provides damage control because the earlier you learn of your mistakes, the less likely you are to repeat those mistakes;

12、Bugs are a form of negative feedback that keep fast but sloppy programmers in check. If you don't allow programmers to work on new features until they have fixed all their bugs, you prevent sloppy programmers from spreading half-implemented features throughout the product----they're too fixing bugs. If you allow programmers to ignore their bugs, you lose that regulation.

13、By keeping that bug count near zero, you have a much easier time predicting when you'll finish the product. Instead of trying to guess how long it will take to finish 32 features and 1742 bug-fixes, you just have to guess how long it will take to finish the 32 features. Even better, you're often in a position to drop the unfinished features and ship what you have.

最新文章

  1. 网站上如何添加显示favicon
  2. 教你一招:解决安装或卸载office时 提示错误2503 2502 发生了内部错误
  3. 解决两台虚拟机互ping可通,但connect失败
  4. yum安装报错有冲突file /usr/lib64/php/modules/fileinfo.so conflicts between
  5. 发送带有认证信息的HTTP请求并取回响应
  6. c++清除输入缓冲区之 sync() vs ignore()
  7. 警惕!MySQL成数据勒索新目标
  8. Scrum Meeting Alpha - 5
  9. October 23, 2013 - Fires and smoke in eastern China
  10. 【代码笔记】Web-CSS-CSS 语法
  11. 在jsp里面 当鼠标元素触发onmouseover时,旁边出现一个浮动且跟随鼠标的div ,移开消失
  12. CF1137C Museums Tour(Tarjan,强连通分量)
  13. JavaScript:event loop详解
  14. JQuery实现省市区的三级联动
  15. <Hadoop><SequenceFile><Hadoop小文件>
  16. Quo JS多种触摸手势轻量级JavaScript库
  17. 实现Quartz的动态增删改查
  18. [置顶] HashTable vs HashMap
  19. 51nod1380 夹克老爷的逢三抽一
  20. Manacher【p1659】 [国家集训队]拉拉队排练

热门文章

  1. ISE联合modelsim功能仿真和综合后仿真
  2. 深入讲解Android Property机制
  3. 枚举操作的常用方法,包括获得枚举的value,name,description
  4. cocos2d-x -- removeChild
  5. DDOS与DDOS追踪的介绍
  6. 递归查询SQL语句
  7. 说说http协议中的编码和解码
  8. Java中常见的异常__
  9. golang socket 实现分析(一)
  10. 【Visual Studio】VS常用调试技巧——笔记