对于面向过程你有着怎样理解的？又是如果理解函数这一概念呢？
众所周知，C语言是面向过程的，如何在使用C在编写代码过程中体现这些过程呢？我的理解是：我们通过函数来体现种种过程。一个完整的C程序通过一个又一个的函数调用来完成自身的全部工作，函数设计得不好，你就等着后面维护的人骂吧。
函数的设计关乎程序是否能让人正确理解，从而进一步的维护。最典型的一个缺陷就是函数承载了太多的任务（我就曾在项目中见过臃肿到几千行的程度的函数。显然这是普通人难以维护的艰巨任务。）
很多的经典教科书与企业的编码标准中一再说明，一个函数只能完成一到两件任务，最好一个函数只做好一件事情。一个好的函数封装能让我们一目了然的了解这个函数用来干什么，它需要怎样的输入与输出。
函数通过参数进行输入，通过返回值将计算结果进行输出。那么参数是不是越多越好呢？我不赞同，参数越多，说明需要函数需要完成的事情就越多，失去了简洁紧凑的特点。而且，我们往往容易将参数的位置弄错，而带入了不易发现的错误，如果此事再将编译警告完全关闭，就等着牺牲你的节假日用来debug吧。
参数最好能控制在两到三个最好，参数太多，一个不方便使用，没有说明很容易用错（总会有些家伙喜欢制造垃圾代码而不留一点注释）。实在太多就打包一个结构体带个地址进去就行了。
例如select函数，
在使用这种函数以前，劝你仔细阅读一下他们的长篇使用说明，还有一系列的宏定义。因为你直接复制过别人代码有可能是一堆错误
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
int pselect(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, const struct timespec *timeout,
const sigset_t *sigmask);
绝大部分标准库函数的参数都在四个以下，简单易懂，使用方便。
函数体最好能在一屏内显示完整，不要翻页，这些才是令人赏心悦目的函数封装。
千万不要让你的函数又臭又长，被人遗臭万年。
一个好的函数封装像一个干净整洁的美女站在你面前令你百看不厌，一个差劲的设计就像是是又邋遢又丑的女人在糟践你的眼球，让你对这个世界感到绝望。
最后举出一个差劲的反面例子，祝你好运！
void vMErrReport(
SINT4 vlSrvId,
SINT2 vnErrLevel,
SINT8 vnErrPos,
const SCHAR* vsapModuleName,
const SCHAR* vsapFileName,
const SCHAR* vsapErrTitle,
const SCHAR* vsapErrDetail,
SINT4 vlReturnVal,
SINT4 vlSysError)
呃，补充一点，业界有种使用宏定义来替代短小函数的习惯，个人不敢苟同。既然Ｃ99中已经出现了关键字inline，同样是替换，为什么不把inline直接放在你的函数前面呢？
宏这种高大上的东西不是我等小人物玩的把戏，玩不好就引火烧身了，请珍重！
刚瞧碰到一个坑爹的宏，编译通不过。微软啊～，windows编程啊～，无标准无规范啊～用ＧCC的伤不起啊～ T_T
#define WORD_LO(xxx) ((byte)((word)(xxx)&255))