2010年6月22日星期二

不要“想当然”地编程

100_2891

本图和本文无关,摄于汉诺威动物园。

很久没有在“电子工程师乱弹编程”这个系列写一些东西,这个系列是我的一些关于编程“自爽文”的集合,今天有点时间,来写一个小小的编程体验。
今天下午又花了一大堆时间来找bug。
经过一番一番的跟踪才发现bug的程序代码。
找到bug后,又是一阵痛心疾首。

花了那么多的时间就是为了一个非常愚蠢的bug。
在代码中,我需要配长度为DEF_I_FRAME_BUFFER_SIZE字节的内存块。
DEF_I_FRAME_BUFFER_SIZE 长度为一个MPEG编码的I Frame的大小。
_last_buf = (uint8_t *)malloc(DEF_I_FRAME_BUFFER_SIZE);
我当时“想当然地”分配了200000。
自认为已经足够大了。

请看以下分析:
如果分辨率为500*500
使用了的是4:2:0 (YV12) --> 12 bit pro Pixel
8 Bit = 1 Byte
那么可以得到maximal frame size:
4:2:0 (YV12) --> 500*500*(12/8) = 375000 Byte = 0.375 MB
哈,就是这样,对于一个500*500一个帧也许会需要375000 Byte,就是这么简单。

“想当然”的足够大的size,就产生了一个愚蠢的bug。
使用malloc固然非常危险,但是最危险的是“想当然”的编程态度。
我常常不够谨慎地进行编程,一味求快。
这常常会出现很多思考的遗漏。
其实,在当时编这段愚蠢的代码的时候,自己问问自己,是这样吗?
如果自己的回答是不太确定,那么就去google一下,就像今天的例子,我当时只需要几分钟google一下,就可以分析出我所需要的buffer的大小。
然而,当时的“想当然”,就会产生后来的一个小时以上时间的浪费。

好了,最后再总结一下。

第一个经验为:
不要“想当然”地编程

第二个小小的经验为:
在动手找bug解决它的时候,一定一定要分析理解一下问题的本质。抓住问题的本质,根本,这很重要。
不要乱猜测bug的来源或者随意随机的修改,这肯定会让你的程序比找bug之前更糟糕。

没有评论: