OceanBase笔记1：代码规范

对自己的要求：

• 了解OceanBase的编码风格（代码规范，异常机制等）
• 了解OceanBase测试如何组织，如何运行的
• 了解OceanBase里都用了哪些设计模式，在什么场景下应用，解决了什么问题
• 可以暂不对其实现原理，进行探究
• 初步只采用静态分析的方式进行学习

---

命名规范：

• 目录：小写
• 文件：小写+下划线
• 类名：驼峰（大驼峰）
• 常量：大写+下划线
• 变量：小写+下划线
• 方法名：小写+下划线
• namespace：小写

我觉得为什么采用了这么多不同的命名风格是不是想使代码从长的样子差异就特别大，肉眼扫过去凭着直觉就知道是什么呢？

---

缩进：

居然是两个空格，绝对不能忍的，不知道是不是因为OB自己的编码风格会造成一行字符太多就缩短了空格数呢？，但是个人觉得这样会操作逻辑层次不清楚，自从写了python以后我就是4空格支持者了（输入还是1tab，配置成4空格长）不过进入一个团队就没办法了，对于团队来说一致编码的风格才是重要的，貌似对于一个团队来说，最高的标准就是所有代码就像同一个人写的：）

---

大刮号：

采用独占1行，上下对齐，我现在也是这样的：），如果只有1行代码还要不要刮号呢？google的编码规范里认为也是必须的，我现在也是这么看的，因为一旦想加几行代码，说不定就把刮号这事给忘了，那么就会造成个bug

---

 注释：

• 每个文件顶部放版权信息，编写人，维护人信息
• .H文件里描述类和类的方法的功能定义，输入输出，然后在.CPP文件里就不再描述
• 含义明确的函数就不用再进行描述（例如没有代码的构造函数，析构函数）
• 其他视感觉而定

---

 注释例子：

/**

 * get the start key of next block

 *  

 * @param block_cache block cache 

 * @param table_id table id of the sstable which the block 

 *                 belongs to

 * @param column_group_id column group id of the sstable which 

 *                 the block belongs to 

 * @param start_key start key of next block 

 * @param reader the sstable reader which the rowkey belong to 

 * 

 * @return int if success,return OB_SUCCESS or OB_ITER_END, else 

 *         return OB_ERROR

 */

 int get_start_key_of_next_block(sstable::ObBlockCache& block_cache, 

                                 uint64_t& table_id,

                                 uint64_t& column_group_id,

                                 common::ObString& start_key,

                                 sstable::ObSSTableReader* sstable_reader = NULL);