我的工程实践选题是《基于LLVM的实时编译器开发》，我在github上找到的一个C语言编译器UCC，地址：https://github.com/sheisc/ucc162.3。（1）用 C 语言来实现 C 编译器，另外就是实现自 举(bootstrap)，这是对编译器的一个很好的测试。 （2）代码简洁易懂，结构清晰，适合学生学习和掌握。 （3）实现 ANSI C89 标准。 （4）编译器的核心难点和复杂度在后端优化，这是一个简单的用来学习基本原理的编 译器，基本不涉及后端优化。
代码结构
白色矩形框为文件夹，黄色为文件。作者把GPL文件、Makefile、readme文件都放在主目录ucc下，每部分的代码都分成不同文件夹，对项目的操作以及项目的相关信息都可以在主目录下找到，这么做十分方便有关源程序的存储、查询、编译、链接等工作。对整个项目的管理都集中在Makefile里，如项目的编译、连接等。每个项目都要有readme文件，所有对项目的说明都集中在README里。作者还设置了测试目录example，所有关键字的测试都在这个目录下进行。但是作者没有设置工具目录，无法很好的存放文件编辑器等工具的信息。此外作者没有设置了doc文件夹存放项目的相关文件如图片等，不是一个好选择
文件名/类名/函数名/变量名等命名
文件名作者使用了完整的单词,因为这个项目结构比较简单，文件基本用一个单词即可表达
函数名作者采用的是多个单词描述，长单词使用头几个字母，多个单词间用下划线大小写分隔，
变量名有的使用多个单词描述，长单词使用头几个字母，多个单词间用下划线大小写分割
代码维护
作者使用github进行维护，每次提交代码都有详细的修改记录
接口定义规范
注释
作者每个头文件都有注释，包含文件名、描述、版本、创建时间、编译器、作者、版权、修改日志等。作者每个函数头部都有注释，主要描述了函数的功能，但是没有指出参数、返回值、调用关系等，这样不利于函数理解的清晰，所以作者对函数的注释不是很好有改进的空间。作者对全局变量没有详细的注释，这样很容易造成混乱，全局变量应该有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等。
总结同类编程语言或项目在代码规范和风格的一般要求
1、注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁
2、全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明
3、在代码的功能、意图层次上进行注释，提供有用、额外的信息
4、标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解，较短的单词可通过去掉“元音”形成缩写；较长的单词可取单词的头几个字母形成缩写；一些单词有大家公认的缩写
5、在同一软件产品内，应规划好接口部分标识符（变量、结构、函数及常量）的命名，防止编译、链接时产生冲突
6、去掉没必要的公共变量
7、仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系
8、不同结构间的关系不要过于复杂
9、检查函数所有非参数输入的有效性，如数据文件、公共变量等
10、函数名应准确描述函数的功能
11、防止把没有关联的语句放到一个函数中
12、减少函数本身或函数间的递归调用
13、尽量减少循环嵌套层次
14、如果一个数据结构，在创建和销毁它的单线执行环境之外可见，那么它必须要有一个引用计数器
15、打印内核消息时，注意内核信息的拼写，不要用不规范的单词比如“ dont”，而要用“do not”或者“don't”。保证这些信息简单、清晰、明了、无歧义
16、如果函数的名字是 一个动作或者强制性的命令，那么这个函数应该返回错误代码 整数。如果是一个判断，那么函数应该返回一个“成功”布尔值。
17、如果一个函数有3行以上，就不要把它变成内联函数。这个原则的一个例外是，如果你知道某个参数是一个编译时常量，而且因为这个常量你确定编译器在编译时 能优化掉你的函数的大部分代码，那仍然可以给它加上inline关键字