杂谈代码组织---弯路集

翻起微软编程规范，google编程规范，第一感觉是好长，好麻烦，为什么要这么做？
问题就出在这里，“我”不知道为什么要这么做。
一般的学习过程是，遇到问题，解决问题，现在的问题就是，没有遇到问题，没有感受困难，就被填一堆解决问题的办法，所以不理解。文艺的表达方式是：不了解痛苦，怎么理解安慰。

解决这个问题的办法是：让“他”接触问题，让“他”感受困难。

最早的hello world，草草数行，放到一个.c里，F5万事大吉。可是后面需要码的代码越来越多，函数多了，放到一个文件里显然不合理，把功能相关度高的函数放到一个.c里，并给予明义的文件名，是合理的办法。于是随着代码量增多，一个.c变成了数个.c

这些分属不同.c里的某些函数需要互相调用，于是在每个.c里都需要声明被调用函数原型。为什么要声明函数原型？随着知识增长，渐渐体会到，编译器以每个.c为编译单元，把.c翻译为机器码。机器码用汇编表示出来看，调用一个函数，需要传递函数参数，压栈需要约定顺序，还要确定谁来清理参数，以及要不要返回值的问题。约定好这些，再只需要函数地址就成了。那么，以每个.c为编译单元，就意味着编译器不去其他.c找需要调用的相关信息，那么调用该函数所需要的约定，就要声明函数类型来告诉编译器。至于函数地址编译器暂时留个空位，等链接的时候填上就行。

还有全局变量，其他.c里要调用，也要告诉编译器，这个变量声明在别的文件里，告诉编译器该变量的类型，让给预留个空位。每个需要调用的.c里都要告知编译器。

结构体在机器码里不存在，会被换算成实际的偏移，但是每个.c都需要通过结构体的声明知道偏移究竟多少。

于是，多个.c都需要的信息，就需要再每个.c里都copy一份，麻烦。
解决方法是，每个.c都把自己需要对外的信息，比如函数原型，比如全局变量的extern，比如结构体，写进.h里，哪个.c要用，自个儿#include一下就好了。

代码继续膨胀，写了很多的.c，每个.c都各异的需要其他若干.c的信息，于是这个.c里开头一堆include，那个.c里一堆include，看着很烦。

解决方法是，对这个工程写一个(公共的).h，该.h里包涵其他所有.h（需要注意顺序），然后每个.c只需要包涵这一个.h即可。

不同的.h有没有递归嵌套的问题？
用这个方法来解决，每个.h开头来一个#pragma once
也可以用#ifndef _XXX_h，#define _XXX_h，#endif // _XXX_h 把所有的内容括起来。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课