1
013231 2012-10-10 05:06:39 +08:00 1
打印日誌查錯效率是O(log n), 單步跟蹤是O(n).
况且單步跟蹤還有很多局限性. |
3
rightgenius 2012-10-10 09:09:43 +08:00
顶1l
|
5
skyleft 2012-10-10 10:17:45 +08:00 3
打印日志第n次成功找到bug的概率是1/n,1/(n-1),1/(n-2)...-> 1,把所有期望值求和取平均=
(1+1/2+1/3+...+1/n)/n=1/n在[1,n]上的定积分=ln(n)-ln(1)=ln(n),所以其复杂度为O(ln n) 单步跟踪找到bug的概率期望值为(1+2+3+...+n)/n=(n+1)/2 所以其复杂度为O(n) |
9
cabbala 2012-10-10 10:31:01 +08:00
Python打日志不用print啊,用logger打,而且还能控制打印的粒度。
|
10
jianingy 2012-10-10 10:38:24 +08:00 1
@013231 单步跟踪可以用breakpoints的
一直用print大法调试,现在正努力摆脱中。原因有两个,一个是学了functional programming另一个是看了rob pike的一个建议。把rob pike的帖子贴这里,这才是正确的debug方法, A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model. Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs. I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software. |
11
skydiver 2012-10-10 10:45:17 +08:00 1
|
12
haohaolee 2012-10-10 10:51:08 +08:00
笑笑就好,有的还不能当真。用调试器又不光是单步,而且用调试器和打印日志也不矛盾
|
14
holmesabc 2012-10-10 12:15:18 +08:00
@haohaolee 同意
就应该说是调试器。 打日志,会直接影响原代码(虽说不会影响逻辑)。 调试器一般那么多功能,运行到指定行,运行到返回什么的 单步的话,我一般是看内存里面变量的值的变化。哪个值不对,在什么地方不对,马上就知道原因。 (当然我说的是java, python还不会用调试器) 如果不是逻辑上的问题,打日志,完全可以。 但是如果是逻辑上的问题,那就蛋疼了。 |
15
binux 2012-10-10 12:23:14 +08:00
print一般都会有日志级别,正式发布的时候不会开那么低的,对源代码不会有影响
用print的时候,输出的地方一般都非常关键,而且信息更为实用 调试时,print更容易在非常大段的代码中定位 调试后,print依旧留在代码中,为下次调试带来便利 |
16
pengdu 2012-10-10 12:50:48 +08:00
不管是python还是c/c++,都习惯打日志,而不喜欢用单步调试工具。
单步调试工具用起来太蹩脚了,效率低。 |
17
clowwindy 2012-10-10 13:01:54 +08:00 1
本来想说些什么的,但有些东西只有你经历过才能有体会,不经历过说了也不能完全理解,经历过不说也会明白,所有我只能建议楼主,从今天开始,在程序的重要步骤,检测到异常输入的时候,进入了不大可能进入的 else 语句的时候,用 logging 模块打印状态信息,包括现在正准备或者已经做了什么,和关键变量的值。等楼主这么做一段时间之后,自然就明白了。
|
18
gonbo 2012-10-10 13:12:31 +08:00 1
thinking bug -> logging bug -> digging bug
|
19
avatasia 2012-10-10 13:39:57 +08:00
原来有明白人知道断点的。
空格缩进这个不能理解, html和代码混杂的project,如果用空格缩进,会相当难受,有时候会非常在意那一点文件传输的体积。 |
20
013231 2012-10-10 15:05:56 +08:00
|
22
jianingy 2012-10-10 16:40:56 +08:00
@013231 其实打印日志的问题上我们的理解也点不同。打印运行日志是必要的也是很有技巧的,大部分生产问题都可以通过运行日志定位。而我所尽量规避的是通过不停在代码中加print语句来调试程序的方式。
|
25
funagi 2012-10-10 18:24:27 +08:00
我以前用断点多,现在用log多,不知道算是进步还是退步。
现在偶尔还是会用断点,不过仅限于C#之类,感觉脚本语言用log更方便,所以python我用log。 |
26
Sherlockhlt 2012-10-11 17:07:34 +08:00
一般我是先print,要是还找不到就debug,要是还找不到就去逛逛v2ex。。好吧我要去继续找bug了再见。
|