算法设计与分析第一周作业

一：编码规范

参考了华为内部代码规范

总体原则 
1、清晰第一 
2、简洁为美 
3、选择合适的风格，与代码原有风格保持一致

1 头文件

原则1.1 头文件中适合放置接口的声明，不适合放置实现。 
 

原则1.2 头文件应当职责单一。 
 

原则1.3 头文件应向稳定的方向包含。 
 

规则1.1 每一个.c文件应有一个同名.h文件，用于声明需要对外公开的接口。 
 

规则1.2 禁止头文件循环依赖。 
 

规则1.3 .c/.h文件禁止包含用不到的头文件。 
 

规则1.4 头文件应当自包含。 
 

规则1.5 总是编写内部#include保护符（#define 保护）。 
 

规则1.6 禁止在头文件中定义变量。 
 

规则1.7 只能通过包含头文件的方式使用其他.c提供的接口，禁止在.c中通过extern的方式使用外部函数接口、变量。 
 

2 函数
原则2.1 一个函数仅完成一件功能。 
 

原则2.2 重复代码应该尽可能提炼成函数。 
 

规则2.1 避免函数过长，新增函数不超过50行（非空非注释行）。 
 

规则2.2 避免函数的代码块嵌套过深，新增函数的代码块嵌套不超过4层。 
 

规则2.3 可重入函数应避免使用共享变量；若需要使用，则应通过互斥手段（关中断、信号量）对其加以保护。 
 

规则2.4 对参数的合法性检查，由调用者负责还是由接口函数负责，应在项目组/模块内应统一规定。缺省由调用者负责。 
 

规则2.5 对函数的错误返回码要全面处理。 
 

规则2.6 设计高扇入，合理扇出（小于7）的函数。 
 

规则2.7 废弃代码（没有被调用的函数和变量)要及时清除。 
 

建议2.1 函数不变参数使用const。 
 

建议2.2 函数应避免使用全局变量、静态局部变量和I/O操作，不可避免的地方应集中使用。 
 

建议2.3 检查函数所有非参数输入的有效性，如数据文件、公共变量等。 
 

建议2.4 函数的参数个数不超过5个。 
 

建议2.5 除打印类函数外，不要使用可变长参函数。 
 

建议2.6 在源文件范围内声明和定义的所有函数，除非外部可见，否则应该增加static关键字。 
 

3 标识符命名与定义
原则3.1 标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。 
 

原则3.2 除了常见的通用缩写以外，不使用单词缩写，不得使用汉语拼音。 
 

规则3.1 产品/项目组内部应保持统一的命名风格。 
 

规则3.2 全局变量应增加“g_”前缀。

规则3.3 静态变量应增加“s_”前缀。 
 

规则3.4 禁止使用单字节命名变量，但允许定义i、j、k作为局部循环变量。

规则3.5 对于数值或者字符串等等常量的定义，建议采用全大写字母，单词之间加下划线„_‟的方式命名（枚举同样建议使用此方式定义）。

规则3.6 除了头文件或编译开关等特殊标识定义，宏定义不能使用下划线„_‟开头和结尾。 
 

4 变量
原则4.1 一个变量只有一个功能，不能把一个变量用作多种用途。 
 

原则4.2 结构功能单一；不要设计面面俱到的数据结构。 
 

原则4.3 不用或者少用全局变量。 
 

规则4.1 防止局部变量与全局变量同名。 
 

规则4.2 通讯过程中使用的结构，必须注意字节序。 
 

规则4.3 严禁使用未经初始化的变量作为右值。 
 

建议4.1 构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的全局变量，防止多个不同模块或函数都可以修改、创建同一全局变量的现象。 
 

建议4.2 使用面向接口编程思想，通过API访问数据：如果本模块的数据需要对外部模块开放，应提供接口函数来设置、获取，同时注意全局数据的访问互斥。 
 

建议4.3 在首次使用前初始化变量，初始化的地方离使用的地方越近越好。 
 

建议4.4 明确全局变量的初始化顺序，避免跨模块的初始化依赖。 
 

建议4.5 尽量减少没有必要的数据类型默认转换与强制转换。 
 

5 宏、常量
规则5.1 用宏定义表达式时，要使用完备的括号。 
 

规则5.2 将宏所定义的多条表达式放在大括号中。 
 

规则5.3 使用宏时，不允许参数发生变化。

规则5.4 不允许直接使用魔鬼数字。 
可能使用函数代替宏。 
 

建议5.2 常量建议使用const定义代替宏。 
 

建议5.3 宏定义中尽量不使用return、goto、continue、break等改变程序流程的语句。 
 

6 质量保证
原则6.1 代码质量保证优先原则 
（1）正确性，指程序要实现设计要求的功能。 
（2）简洁性，指程序易于理解并且易于实现。 
（3）可维护性，指程序被修改的能力，包括纠错、改进、新需求或功能规格变化的适应能力。 
（4）可靠性，指程序在给定时间间隔和环境条件下，按设计要求成功运行程序的概率。 
（5）代码可测试性，指软件发现故障并隔离、定位故障的能力，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。 
（6）代码性能高效，指是尽可能少地占用系统资源，包括内存和执行时间。 
（7）可移植性，指为了在原来设计的特定环境之外运行，对系统进行修改的能力。 
（8）个人表达方式/个人方便性，指个人编程习惯。

原则6.2 要时刻注意易混淆的操作符。 
 

原则6.3 必须了解编译系统的内存分配方式，特别是编译系统对不同类型的变量的内存分配规则，如局部变量在何处分配、静态变量在何处分配等。

原则6.4 不仅关注接口，同样要关注实现。 
 

规则6.1 禁止内存操作越界。 
 

规则6.2 禁止内存泄漏。 
 

规则6.3 禁止引用已经释放的内存空间。 
 

规则6.4 编程时，要防止差1错误。 
 

规则6.5 所有的if … else if结构应该由else子句结束 ；switch语句必须有default分支。

（规则原博：https://blog.csdn.net/LIAOYUANGANG/article/details/79174627 ）

二：《数学之美》统计语言模型感悟
       在数学之美第三章—《统计语言模型》中，吴军提到，人类一致梦想着让机器人代替人来翻译语言，识别语音，认识文字和进行海量文献的自动检索。因此这就需要让机器来理解语言。贾里尼克领导一批杰出的科研人员提出的统计语言模型，也被证明了比任何已知的借助某种规则的解决方法都有效。
      而这个统计语言模型，便是借助了数学知识，也就是用数学上所说的概率来表示一个词语在文本中出现的可能性。这是因为机器对语言的识别，从某种程度上来说就是要知道某个词语在文本中出现的概率。基于这个数学理解，统计语言模型给出了计算一个词出现在文本中可能性的计算公式。在这个计算公式的基础上，后面的问题便变得简单了起来。
      看起来如此简单的数学模型，却解决了复杂的语音识别，机器翻译等问题，这或许就是数学的奥妙之处。数学使一些问题简单化。在最开始人们提出使用“形式语言”的语法规则来进行文字处理，但基于这个语法规则的方法却在几十年内都毫无进展。引入数学模型后问题变得相对容易解决了起来。数学的美妙之处便体现在这里。
       在本章节中，吴军还提到，数学家兼信息论的祖师爷香农也曾提出用数学模型的方法来处理自然语言，但是碍于当时计算机的条件，大量的信息无法处理。直到大规模集成电路的快速计算机出现后，香农的梦想才得以实现。由此可见，计算机的发展对科技的进步起着至关重要的作用。
        以上便是我阅读了《数学之美》第三章统计语言模型后的一些感悟与想法。