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

[软工2103李天毅]

#参考谷歌编程规范：

1. 命名约定

最重要的一致性规则是命名管理. 命名风格快速获知名字代表是什么东东: 类型? 变量? 函数? 常量? 宏 ... ? 甚至不需要去查找类型声明. 我们大脑中的模式匹配引擎可以非常可靠的处理这些命名规则.

命名规则具有一定随意性, 但相比按个人喜好命名, 一致性更重, 所以不管你怎么想, 规则总归是规则.

1.1. 通用命名规则

Tip

函数命名，变量命名，文件命名要有描述性；少用缩写。

尽可能给有描述性的命名，别心疼空间，毕竟让代码易于新读者理解很重要。不要用只有项目开发者能理解的缩写，也不要通过砍掉几个字母来缩写单词。

int price_count_reader;    // 无缩写
int num_errors;            // “num” 本来就很常见
int num_dns_connections;   // 人人都知道 “DNS” 是啥

1.2. 文件命名

Tip

文件名要全部小写, 可以包含下划线 (_) 或连字符 (-). 按项目约定来. 如果并没有项目约定，”_” 更好。

可接受的文件命名:

* my_useful_class.cc
* my-useful-class.cc
* myusefulclass.cc
* muusefulclass_test.cc // ``_unittest`` 和 ``_regtest`` 已弃用。

1.3. 类型命名

Tip

类型名称的每个单词首字母均大写, 不包含下划线: MyExcitingClass, MyExcitingEnum.

所有类型命名 —— 类, 结构体, 类型定义 (typedef), 枚举 —— 均使用相同约定. 例如:

// classes and structs
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...

// typedefs
typedef hash_map<UrlTableProperties *, string> PropertiesMap;

// enums
enum UrlTableErrors { 

 

1.4. 变量命名

Tip

变量名一律小写, 单词之间用下划线连接. 类的成员变量以下划线结尾, 但结构体的就不用，如::a_local_variable, a_struct_data_member, a_class_data_member_.

普通变量命名:

举例:

string table_name;  // 可 - 用下划线。
string tablename;   // 可 - 全小写。

Warning

string tableName;   // 差 - 混合大小写。

类数据成员：

不管是静态的还是非静态的，类数据成员都可以和普通变量一样, 但要接下划线。

class TableInfo {
  ...
 private:
  string table_name_;  // 可 - 尾后加下划线。
  string tablename_;   // 可。
  static Pool<TableInfo>* pool_;  // 可。
};

结构体变量:

不管是静态的还是非静态的，结构体数据成员都可以和普通变量一样, 不用像类那样接下划线:

struct UrlTableProperties {
    string name;
    int num_entries;
}

结构体与类的讨论参考 结构体 vs. 类 一节.

全局变量:

对全局变量没有特别要求, 少用就好, 但如果你要用, 可以用  g_ 或其它标志作为前缀, 以便更好的区分局部变量.

1.5. 常量命名

Tip

在全局或类里的常量名称前加 k: kDaysInAWeek. 且除去开头的 k 之外每个单词开头字母均大写。

所有编译时常量, 无论是局部的, 全局的还是类中的, 和其他变量稍微区别一下. k 后接大写字母开头的单词:

const int kDaysInAWeek = 7;

这规则适用于编译时的局部作用域常量，不过要按变量规则来命名也可以。

1.6. 函数命名

Tip

常规函数使用大小写混合, 取值和设值函数则要求与变量名匹配: MyExcitingFunction(),MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().

常规函数:

函数名的每个单词首字母大写, 没有下划线。

如果您的某函数出错时就要直接 crash, 那么就在函数名加上 OrDie. 但这函数本身必须集成在产品代码里，且平时也可能会出错。

AddTableEntry()
DeleteUrl()
OpenFileOrDie()

取值和设值函数:

取值（Accessors）和设值（Mutators）函数要与存取的变量名匹配. 这儿摘录一个类,num_entries_ 是该类的实例变量:

class MyClass {
    public:
        ...
        int num_entries() const { return num_entries_; }
        void set_num_entries(int num_entries) { num_entries_ = num_entries; }

    private:
        int num_entries_;
};

其它非常短小的内联函数名也可以用小写字母, 例如. 如果你在循环中调用这样的函数甚至都不用缓存其返回值, 小写命名就可以接受.

1.7. 名字空间命名

Tip

名字空间用小写字母命名, 并基于项目名称和目录结构: google_awesome_project.

关于名字空间的讨论和如何命名, 参考 名字空间 一节.

1.8. 枚举命名

Tip

枚举的命名应当和 常量 或 宏 一致: kEnumName 或是 ENUM_NAME.

单独的枚举值应该优先采用  常量 的命名方式. 但  宏 方式的命名也可以接受. 枚举名  UrlTableErrors(以及  AlternateUrlTableErrors) 是类型, 所以要用大小写混合的方式.

enum UrlTableErrors {
    kOK = 0,
    kErrorOutOfMemory,
    kErrorMalformedInput,
};
enum AlternateUrlTableErrors {
    OK = 0,
    OUT_OF_MEMORY = 1,
    MALFORMED_INPUT = 2,
};

2009 年 1 月之前, 我们一直建议采用 宏 的方式命名枚举值. 由于枚举值和宏之间的命名冲突, 直接导致了很多问题. 由此, 这里改为优先选择常量风格的命名方式. 新代码应该尽可能优先使用常量风格. 但是老代码没必要切换到常量风格, 除非宏风格确实会产生编译期问题.

1.9. 宏命名

Tip

你并不打算:ref:使用宏 <preprocessor-macros>, 对吧? 如果你一定要用, 像这样命名:MY_MACRO_THAT_SCARES_SMALL_CHILDREN.

参考:ref:预处理宏 <preprocessor-macros>; 通常 不应该 使用宏. 如果不得不用, 其命名像枚举命名一样全部大写, 使用下划线:

#define ROUND(x) ...
#define PI_ROUNDED 3.0

1.10. 命名规则的特例

Tip

如果你命名的实体与已有 C/C++ 实体相似, 可参考现有命名策略.

bigopen():

函数名, 参照  open() 的形式

uint:

typedef

bigpos:

struct 或  class, 参照  pos 的形式

sparse_hash_map:

STL 相似实体; 参照 STL 命名约定

LONGLONG_MAX:

常量, 如同  INT_MAX

 

2. 读《数学之美》

第六章
小结
在这个大数据的时代，信息已经成为像水电这样的基础的可以随意获取的资源了，但正如老师在课堂上讲的数据本身是没有用的，只有被分析后的数据才有价值，我觉得身为计科这种走在世界前列的学科的成员，一定要知道如何去分析处理数据让他变得有价值。

第七章
小结
观大师的一生我只有在内心无比的敬仰，但大师的成功一定是有理由的，贾里尼克我觉得他的成功一定离不开他一生的学习，和他的勤勉还有学术严谨，还有作者所说的一个人要在自己的领域做到世界一流，他的周围必定有非常多世界一流的人物。

第八章
第八十二页
技术分为术和道两种，具体做事的方法是术，做事的原理和原则是道。追求术的人一辈子工作很辛苦，只有掌握了搜索的本质和精髓才能永远游刃有余。

许多人学习计算机都只是囫囵吞枣，包括我自己很多东西都不求原理，只关注应用，很多地方都只关心接口但是却不深究别人的库和框架是如何实现的，在这里给自己一个小警告勿一味的去追求术反而冷落了自己的道的打磨

第八十八页
牛顿说过：“（人们）发觉真理在形式上从来都是简单的，而不是复杂和含混的。”

而数学在计算机领域的作用也是如此的，通过各种模型去简化问题，从而我想到了虽然现在我们的技术周期大大缩短，但是在科学的思想和方向上其实与几百年前的其实区别不大。