高质量代码

• 各种边界条件是否考虑完备
• 异常情况处理,稳定性保证
• 易读易维护

编程原则

• 简单性

    消除“多余的复杂性”，以简单清晰的逻辑编写代码。
    不理解的代码无法修复改进
  

• 可读性

    代码是写给人看的，而不是机器
    编写可维护代码的第一步是确保代码可读
  

• 生产力

    团队整体工作效率非常重要
  

编码规范

    包中声明的每个公共的符号:变量、常量、函数以及结构都需要添加注释

    任何既不明显也不简短的公共功能必须予以注释

    无论长度或复杂程度如何,对库中的任何函数都必须进行注释

代码格式

使用gofmt自动格式化代码为官方统一风格

注释

注释应该做的

       注释应该解释代码作用
       注释应该解释代码如何做的
       注释应该解释代码实现的原因
       注释应该解释代码什么情况会出错
       注释应该提供代码未表达出的上下文信息

命名规范

• 变量命名

  简洁胜于冗长

缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写

例如使用ServeHTTP而不是ServeHttp
使用XMLHTTPRequest或者xmlHTTPRequest

变量距离其被使用的地方越远，则需要携带越多的上下文信息

全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义

• 包名命名

    只由小写字母组成。不包含大写字母和下划线等字符。
  
    简短并包含一定的上下文信息。例如schema、task 等。
  
    不要与标准库同名。例如不要使用sync或者strings
  

流程控制

• 尽量避免嵌套分支
• 尽量保持正常代码路径为最小缩进

性能优化

性能优化手段

• 使用benchmark工具对基准性能进行测试

• slice尽量提前使用make预分配内存

大内存未释放

·在已有切片基础上创建切片，不会创建新的底层数组。

场景
·原切片较大，代码在原切片基础上新建小切片·原底层数组在内存中有引用，得不到释放·可使用copy替代re-slice

eg：

（orgin是一个1MB大小的切片）

使用benchmark对比性能

• map使用前也应提前预分配内存

• 字符串处理，最好使用strings.Builder类型进行字符串拼接，修改，增加等操作，然后再转化成string。

有一个leetcode每日一题我比较有印象，在ver1我直接使用的string进行操作，但是超时了，后我改用strings.Builder就ac了

原因：

字符串在Go语言中是不可变类型，占用内存大小是固定的·使用＋每次都会重新分配内存
. strings.Builder，bytes.Buffer底层都是[byte 数组·内存扩容策略，不需要每次拼接重新分配内存

• 空结构体不占用内存空间

这在我刷算法其实还挺常用的，有时候需要使用map去存储数据，但是vaule没太多实际意义，这就可以直接用空结构体，节省内存

• automic包