1
greatghoul 2013-05-28 17:07:09 +08:00
1. 代码规范
等你到了单位,许多单位都有现在的代码指导规范,甚至一些公司已经具体化到了 IDE 中,会自动提醒你写出符合公司要求的代码,所以单靠代码风格不太能很准确的判断一个人的能力。 真正的水平,体现在代码的质量上,而不是风格,漂亮的解决业务中的问题,同时容易阅读,注释得当,逻辑清晰,很少重复,一般来说,就是好代码。 2. 关于调试。 我没有写过 C ,但说说我调试的方法,我会优先使用日志覆盖,在关键的位置打上合理级别和内容的日志。这样做有如下好处。 - 不需要断点,哪里出错从日志上大概就能看出来,然后直接察看日志附近的代码 - 为以后考虑,试想到了生产环境,你哪里还有机会去设置断点,如果真的程序出了问题, 通过历史的日志,还能了解一些现场的情况,这些都是断点做不到的。 当然了,最好是两者结合起来用,对于一些问题,断点的确比日志要快一些,但是尽量少用吧。 仅是个人经验 |
2
fangzhzh 2013-05-28 17:10:45 +08:00
debug: 一般问题, printf, 教严重的dump core 的问题: gdb
学习debug, gdb cheetsheep是你的好朋友, 附上 google第一个结果: http://darkdust.net/files/GDB%20Cheat%20Sheet.pdf 我当时用gdb的时候,打了一份在手边 内存泄漏 linux 的话, valgrind, 你用了绝对会喜欢. 题外话: 很早看过一句话: debug is the mother of all evils, 当时不以为然. 慢慢的发现, 流程很重要. debug解决的是语法,最多是逻辑的问题, 对流程问题无能为力. 有时候,如果很长时间的调试, 改来改去,有时代码能用,有时代码不能用,那么就跳出来想一想,是不是流程不对, 有时候流程对了,就会少很多莫名其妙的错误. |
3
alexrezit 2013-05-28 17:14:08 +08:00
扯淡. 从学习编程 (Objective-C 是我的入门语言) 第一天起我就开始保证大小写命名规则缩进风格完全和官方一致了, 甚至不清楚的时候还会花上很久去读官方的源码.
|
4
alexrezit 2013-05-28 17:18:09 +08:00
另外说句题外话: 虽然我认识的人不是很多, 但在我所认识的编码风格干净整齐的人与编码风格乱糟糟的人这两种人之间, 收入差距可以达到 2-5 倍, 技术水平和文明程度 (例如平时讲话的用词, 行为习惯, 出版物和软件的正版率等等) 也相差甚远.
|
5
efi 2013-05-28 18:13:27 +08:00 1
内核panic只打印一串函数调用栈,内核开发者光看这一串调用就能看出问题所在。为什么?因为他们非常理解在问题发生路径上这些函数应该做什么,不应该做什么。debug最终是要理解代码的目的,发现程序体现出什么与此目的不一致的状态,才能真正解决问题。用debugger补东补西只是治标,不能增加对程序的理解。
我采取的一般做法是:发现症状以后 1. 找到发生症状的代码位置(看日志、core)。 2. 理解上下文代码。 3. 根据症状对问题发生的位置、原因提出几个快速猜想。 4. 实验重现,在相应的地方查看程序状态是否符合设计,猜想是否成立: 5a. (对于小程序)如果没有猜想成立,在代码调用流程上加printf做二(多)分查找,缩小范围,直到找到某一处程序状态不符合设计,转3。 5b. (对于大程序)如果没有猜想成立,按照代码提交历史作二分查找(git bisect),直到找到两个相邻版本不一致,查看差异代码,转5a或3。 6. 猜想成立,修复,再重现一次验证修复。结束。 其实这就是分治法+科学方法 https://en.wikipedia.org/wiki/Scientific_method 调试工具主要适用于难以通过修改程序来实验测试猜想的环境(比如生产环境,特殊架构,特殊设备,自动化)。 |
6
efi 2013-05-28 18:19:31 +08:00
对了,调试实验的时候打开ccache可以大幅提高重新编译速度。
|