Bajins

# 编程规范

# Flag

UUID（Universally Unique Identifier）/GUID (Globally Unique Identifier)

  • Version 1: 基于时间戳和MAC地址，结合当前的时间戳（从格里高利历的1582年10月15日零点算起，100纳秒为单位）和计算机的MAC地址（或伪随机节点ID）。还包含一个“时钟序列”以处理时钟回拨和生成重复MAC地址的情况。
  • Version 2: 类似 Version 1，但将时间戳的高位替换为“DCE Security”域（如用户ID或组ID）。
  • Version 3: 基于命名空间和MD5散列，将一个“命名空间UUID”和一个“名称”（任意字符串）作为输入，然后通过MD5散列算法计算出。
  • Version 4: 基于随机数，大部分位由高质量的伪随机数生成器 (PRNG) 填充。只有几个位用于表示版本号和变体。
  • Version 5: 基于命名空间和SHA-1散列，类似 Version 3，但使用SHA-1散列算法代替MD5。

ULID（Universidally Unique Lexicographically Sortable Identifier）是一种设计用于解决传统 UUID 在数据库索引和可排序性方面缺点的新型标识符。ULID 结合了 UUID 的全球唯一性和时间戳的可排序性。

编程语言提供的随机数，是伪随机数，所谓伪随机数，并非真的随机，而是算法得到的。只要初始的种子值相同，算法会给出一样的结果。 一般来说，只有通过硬件，才能得到真随机数，单纯的软件算法做不到。真随机数需要满足三个条件。

  1. 无法预测。 随机数不能被猜到，所以必须非常大，否则会被暴力破解。
  2. 不能重复。 每次生成的随机数，不能是一样的。
  3. 均匀分布。 随机数必须平均散布在所有区间，不能集中在某些区间。

boolean

bool表示布尔型变量，bai也du就是逻辑型变量的定义符，zhi以英国数学家、布尔代数的奠基人乔dao治·布尔（George Boole）命名。

布尔型变量bool的取值只有false和true，0为false，非0为true。（例如-1和1都是true）

日期时间字符格式表示法

  • ISO 8601(第一版为ISO8601:1988，第二版为ISO8601:2000，第三版ISO8601:2004)：国际标准，每周从周一开始，每年的第一周至少包含4天
  • Common：通用标准，每周从周日开始，每年的第一周至少包含1天

# 代码风格指南

naming conventions 约定大于配置

可读性：程序是供人类阅读和理解的，计算机的执行只是附带的事情。

展开查看思维导图

# 命名规范

  • 匈牙利命名法(Hungarian)：变量类型缩写+大驼峰，如int iMyAge，Windows编程常用
  • 驼峰命名法(camelCase/lowerCamelCase，小驼峰)： 首字母小写，后续每个单词首字母都大写。面向对象语言(如Java、C#)变量、方法常用
  • 帕斯卡命名法(CamelCase/PascalCase，大驼峰)： 首字母大写，后续每个单词首字母都大写。常被面向对象语言(如Java、C#)类常用
  • 下划线命名法(under_score_case/snake_case，Snake蛇形)：C、Python变量、数据库命名常用
  • 短横线命名法(kebab-case)：Web前端语言(如CSS)变量常用，HTML 特性是不区分大小写的，无法使用驼峰命名
  • 不区分大小写(case-insensitive)：Canonical 格式，一般用于HTTP Headers、URL Path

Java

大小写敏感的，且只能以 字母、$、_ 开头，首字母随后的字符可以是字母、数字、$、_

  • 项目名：全部小写，可使用-或_连接符以分割单词，且不能有空格、中文和其他特殊字符
  • 包名：全部小写，单词不需分割，且不能有空格、中文和其他特殊字符
  • 常量：全部大写，可使用_连接符以分割单词
  • 变量：小驼峰式命名法，前缀应当是名词。尽量在变量名字中体现所属类型，如：length、count表示数字类型；name、title表示字符串类型
  • 函数：小驼峰式命名法，前缀应当为动词。
  • 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
  • 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。注意，即使纯拼音命名方式也要避免采用。
  • 类名使用大驼峰风格，但以下情形例外：DO / BO / DTO / VO / AO / PO等。
  • 方法名、参数名、成员变量、局部变量都统一使用小驼峰风格，必须遵从小驼峰形式。
  • 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
  • 抽象类命名使用Abstract或Base开头。
  • 异常类命名使用Exception结尾。
  • 测试类命名以它要测试的类名开始，以Test结尾。
  • 类型与中括号紧挨相连来定义数组。
  • POJO类中布尔类型的变量，都不要加is前缀，否则部分框架解析会引起序列化错误。
  • 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
  • 杜绝完全不规范的缩写，避免望文不知义。
  • 最好逐一声明每个变量而不是写在一行。
  • Java的变量声明尽量靠近变量第一次使用的地方。

# Golang

可见性（访问控制）取决于其第一个字符是否为大写

  • 包名称：其他字母应该为小写单词，不要使用下划线或者混合大小写
  • 文件命名：尽量采取有意义的文件名，简短，有意义，应该为小写单词，使用下划线分隔各个单词
  • 结构体、接口、变量：使用驼峰命名法
  • 常量：全部大写字母组成，并使用下划线分词
  • 单元测试：文件名命名规范为_test结尾，测试用例的函数名称必须以Test开头

# Python

  • 文件名、包名、模块名、局部变量名、函数&方法名：全小写+下划线式驼峰
  • 类：首字母大写式驼峰。内部类可以使用额外的前导下划线
  • 函数和方法的参数
    • 类实例方法第一个参数使用self, 类方法第一个参数使用cls
    • 如果一个函数的参数名称和保留的关键字冲突，通常使用一个后缀下划线好于使用缩写或奇怪的拼写
  • 全局变量
    • 对于from M import *导入语句，如果想阻止导入模块内的全局变量可以使用旧有的规范，在全局变量上加一个前导的下划线。
    • 全大写+下划线式驼峰，应避免使用全局变量
  • 变量
    • 不论是类成员变量还是全局变量，均不使用 m 或 g 前缀。
    • 私有类成员使用单一下划线前缀标识，多定义公开成员，少定义私有成员。
    • 变量名不应带有类型信息，因为Python是动态类型语言，在解释的时候才确定类型
  • 常量
    • 所有字母大写，由下划线连接各个单词
  • 异常
    • 因为异常也是一个类，所以遵守类的命名规则。此外，如果异常实际上指代一个错误的话，应该使用Error做后缀
  • 缩写命名应当尽量使用全拼写的单词，缩写的情况有如下两种：
    • 常用的缩写，如XML、ID等，在命名时也应只大写首字母，如XmlParser。
    • 命名中含有长单词，对某个单词进行缩写。这时应使用约定成俗的缩写方式。
    function 缩写为 fn
text 缩写为 txt
object 缩写为 obj
count 缩写为 cnt
number 缩写为 num

关于下划线

  • 一个前导下划线：表示私有。
  • 一个后缀下划线：避免关键字冲突。
  • 以单下划线开头，是弱内部使用标识，from M import * 时，将不会导入该对象（python 一切皆对象）。
  • 两个前导下划线：当命名一个类属性引起名称冲突时使用。
  • 两个前导和后缀下划线：有特殊用途的对象或者属性，例如init或者file。绝对不要创造这样的名字，而只是使用它们。
  • 以双下划线开头的变量名，主要用于类内部标识类私有，不能直接访问。
  • 双下划线开头且双下划线截尾的命名方法尽量不要用，这是标识

# GNU风格版本规则

  • MAJOR.MINOR.PATCH即： 主版本号.次版本号.修正版本号
  • Major.Minor.Revision即： 主版本号.次版本号.修正版本号

  1. Major 主版本号：表示当前APR的主版本号，它的变化通常意味着APR的巨大的变化，比如体系结构的重新设计、API的重新设计、 重大的重构、重大的feature改动、重大的不兼容性的变化等等，而且这种变化通常会导致APR版本的向前不兼容。

  2. Minor 次版本号：发布较大的新feature功能，或者较大的重构或者模块变化，或者出现不兼容性改动，会增加子版本号； 子版本的发布会伴随着完整的change log，算是一个较大的版本发布，有仪式感

  3. Revision/PATCH 修正版本号：往往是bug fix，或者增加较小的feature，较小的功能改进或者模块变化， 在保证完整向后兼容的前提下，会增加修正版本号

  4. 当主版本号增加时，子版本号及修正版本号置0

  5. 当子版本号增加时，修正版本号置0

按照测试过程标识

  1. Alpha版：预览版或内部测试版，一般不向外部发布，会有很多Bug。
  2. Beta版：公测版。
  3. RC版：Release Candidate候选版本。也叫做Gamma版本。

# Commit提交规范

  • bugfix/fix/fixed: 表示修复 bug
  • feature: 表示增加新功能
  • add: 表示增加类、文件、代码块等
  • delete/del: 表示删除类、文件、代码块等
  • update: 表示对代码块、功能的更新
  • refactor: 表示对代码块、功能重构（即不是新增功能，也不是修改bug的代码变动）
  • arch: 表示输出中间版本，用于测试等
  • release to v1.0.0: 表示打包输出的版本号
  • test：增加测试
  • chore：构建过程或辅助工具的变动
  • mod 修改
  • changed ( 完成的任务 )
  • rem:移除（Remove,移除功能）
  • feat：新功能（feature）
  • docs：文档（documentation）
  • style：格式（不影响代码运行的变动）

# switch

  • 在Python中没有switch语法
  • JavaScript的switch语法跟Java一样
  • 在Java中

如果default不是switch代码块中最后一个case，请记得用break;结束默认case。

switch ("A".toLowerCase()) {
case "a":
    System.out.println("a");
    // 注意：此处如果条件满足但没有添加break，则代码会继续执行，
    // 会无条件执行后面的语句，直到遇到break
    //break;
    // fall thorugh
case "b":
    System.out.println("b");
    break;
default:
    // 如果default写在最前面，会先执行，
    // 但是如果没有写break;还是会无条件执行后面的语句
    System.out.println("default");
    break;
}
  • 在Go中
  1. 左花括号{必须与switch处于同一行；
  2. 条件表达式不限制为常量或者整数；
  3. 单个case中，可以出现多个结果选项，以,分割；
  4. 与C语言等规则相反，Go语言不需要用break来明确退出一个case；
  5. 只有在case中明确添加fallthrough关键字，才会继续执行紧跟的下一个case；
  6. 可以不设定switch之后的条件表达式，在此种情况下，整个switch结构与多个if...else...的逻辑作用等同。
switch strings.ToLower("A") {
case "a":
    fmt.Println("a")
case "b":
    fmt.Println("b")
default:
    fmt.Println("default")
}

← 表达式和编码 →