不要“想当然”地编程

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

很久没有在“电子工程师乱弹编程”这个系列写一些东西，这个系列是我的一些关于编程“自爽文”的集合，今天有点时间，来写一个小小的编程体验。
今天下午又花了一大堆时间来找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之前更糟糕。