PolarDB for PostgreSQLPolarDB for PostgreSQL
  • 架构简介
  • 快速部署
  • 进阶部署
  • 共享存储设备的准备

    • 阿里云 ECS + ESSD 云盘存储
  • 文件系统的准备

    • 格式化并挂载 PFS
  • 部署 PolarDB-PG 数据库

    • 基于单机文件系统部署
    • 基于 PFS 文件系统部署
  • 更多部署方式

    • 购买商业版
  • 日常运维

    • 备份恢复
    • 共享存储在线扩容
    • 计算节点扩缩容
    • Replica 节点在线 Promote
  • 问题诊断

    • CPU 使用率高的排查方法
  • 性能测试

    • TPC-C 测试
    • TPC-H 测试
  • 功能分类

    • 高性能
    • 高可用
    • 安全
    • 弹性跨机并行查询(ePQ)
    • 第三方插件
  • PolarDB for PostgreSQL

    • 特性总览
    • HTAP 架构详解
    • 缓冲区管理
    • DDL 同步
    • LogIndex
  • PostgreSQL

    • ANALYZE 源码解读
    • Sequence 使用、原理全面解析
  • 基于 Docker 容器开发
  • 定制开发环境
  • 贡献代码
  • 贡献文档
  • 编码风格
  • 问题报告
  • English
  • 简体中文
GitHub
  • 架构简介
  • 快速部署
  • 进阶部署
  • 共享存储设备的准备

    • 阿里云 ECS + ESSD 云盘存储
  • 文件系统的准备

    • 格式化并挂载 PFS
  • 部署 PolarDB-PG 数据库

    • 基于单机文件系统部署
    • 基于 PFS 文件系统部署
  • 更多部署方式

    • 购买商业版
  • 日常运维

    • 备份恢复
    • 共享存储在线扩容
    • 计算节点扩缩容
    • Replica 节点在线 Promote
  • 问题诊断

    • CPU 使用率高的排查方法
  • 性能测试

    • TPC-C 测试
    • TPC-H 测试
  • 功能分类

    • 高性能
    • 高可用
    • 安全
    • 弹性跨机并行查询(ePQ)
    • 第三方插件
  • PolarDB for PostgreSQL

    • 特性总览
    • HTAP 架构详解
    • 缓冲区管理
    • DDL 同步
    • LogIndex
  • PostgreSQL

    • ANALYZE 源码解读
    • Sequence 使用、原理全面解析
  • 基于 Docker 容器开发
  • 定制开发环境
  • 贡献代码
  • 贡献文档
  • 编码风格
  • 问题报告
  • English
  • 简体中文
GitHub
  • 参与社区

    • 贡献代码
    • 贡献文档
    • 编码风格
    • 问题报告

编码风格

警告

需要翻译

Languages

  • PostgreSQL kernel, extension, and kernel related tools use C, in order to remain compatible with community versions and to easily upgrade.
  • Management related tools can use shell, GO, or Python, for efficient development.

Style

  • Coding in C follows PostgreSQL's programing style, such as naming, error message format, control statements, length of lines, comment format, length of functions and global variables. In detail, please refer to PostgreSQL style. Here is some highlines:

    • Code in PostgreSQL should only rely on language features available in the C99 standard
    • Do not use // for comments
    • Both, macros with arguments and static inline functions, may be used. The latter is preferred only if the former simplifies coding.
    • Follow BSD C programming conventions
  • Programs in shell can follow Google code conventions

  • Program in Perl can follow official Perl style

Code design and review

We share the same thought and rules as Google Open Source Code Review.

Before submitting code review, please run unit test and pass all tests under src/test, such as regress and isolation. Unit tests or function tests should be submitted with code modification.

In addition to code review, this document offers instructions for the whole cycle of high-quality development, from design, implementation, testing, documentation to preparing for code review. Many good questions are asked for critical steps during development, such as about design, function, complexity, testing, naming, documentation, and code review. The documentation summarizes rules for code review as follows. During a code review, you should make sure that:

  • The code is well-designed.
  • The functionality is good for the users of the code.
  • Any UI changes are sensible and look good.
  • Any parallel programming is done safely.
  • The code isn't more complex than it needs to be.
  • The developer isn't implementing things they might need in the future but don't know they need now.
  • Code has appropriate unit tests.
  • Tests are well-designed.
  • The developer used clear names for everything.
  • Comments are clear and useful, and mostly explain why instead of what.
  • Code is appropriately documented.
  • The code conforms to our style guides.
在 GitHub 上编辑此页
上次更新:
贡献者: Shijun.Zhou
Prev
贡献文档
Next
问题报告