代码规范是编程界里老生常谈的事情，有一句谚语中亦有记载：
程序员最讨厌的两件事:
1.自己写注释
2.别人不写注释
代码规范绝不是随口空谈而已的，实际上的确会带来非常严重的后果：
不过好在我们通常不需要面对如此危险的周围环境，不过遵循一定的规范来编写代码依旧非常必要。
Dave Chency 在《Go 语言最佳实践》一书中提出了三大指导原则：
- 简单性
- 可读性
- 生产力
首先第一条，如果我们的程序过于复杂，那么修改它将会变得极为困难，于是我们会选择用更复杂的代码来添加功能，最终形成了屎山代码。如果想要保持程序拥有高可维护性，那么最好让你的代码足够简单。
而第二条，代码不仅仅是给机器看的，更主要是考虑给人类看。如果你的代码完全看不懂，那不如直接用汇编或者机器语言编程好了。虽然一些朋友们会推崇“防御性编程”的做法把代码故意写的复杂防止自己被公司解雇，但也要考虑到也许不仅仅是别人要面对你的代码，在六个月后你自己再回顾代码时也会一头雾水。
最后是生产力一条。Go程序员不会花费整天的时间来调试不可思议的编译错误，也不会将浪费时间在构建脚本或在生产中部署。最重要的是，他们不用花费时间来试图理解同事所写的内容。
下面是一些细则：
代码格式
代码格式在代码规范中也许是最重要的，不论是什么样的代码，你首先看到的都是整体的格式。当然这里并不是要求你完全按规范来编写代码和敲空格，这样也是浪费时间。可以使用gofmt等工具来自动整理代码。
注释
正如上面所说，我们希望别人的代码有注释，但自己又不喜欢写注释。
某种程度上来说，优秀的代码应该是能够自我解释的，即使不需要注释别人也能轻易看懂。而坏的代码则需要很多注释。
不过，一方面我们不能确定自己的代码对别人或者六个月以后的自己来说清晰易懂；另外用英文编写的代码本身也有阅读门槛。所有如果想要确保代码是“优秀”的，最好还是加上注释。
首先注释应该解释代码的作用，例如官方库等会对其提供的每一个组件做详细解释；其次应该用注释来解释一段复杂逻辑是怎么工作的(不要花大力气去解释i++等一眼就懂的事情)；另外你也可以解释一段代码为什么这样做；最后是注释一段代码可能出错的情况。
命名规范
首先，命名应该简单(但不是完全是像NIO这样的缩写)；其次，如果命名的位置和使用的地方相距很远，那么名字里应该带上上下文信息以便明确意义。
例如说，一个循环的i变量，由于只在一个地方用，那么叫i也无所谓了；但如果是一个定义在开头但使用在末尾的结构体，最好明确标记它是做什么用的。
另外，例如在函数参数表中，参数名最好也要反映其作用，不要使用abc等来命名。
最后是函数命名。首先函数名不需要携带包名，例如你不需要使用
time.NowTime(), 因为包名本身已经包含了这个信息。
以此推导，如果你的返回值也包含有包名，那么也不需要在函数名里面写上包名，例如time.Now()比time.NowTime()好一些。
但是如果返回值不一样，此时就要标明了：time.NowDay()
最后是package命名。记住，其名字应当由小写字母组成；其次，不要和标准库同名。另外使用单数(不要使用products而是使用product)，并且不要随意使用缩写。
流程控制
有一种思想叫做“无缩进编程”大概意思就是在代码中尽量少使用缩进。在代码中制造缩进的罪魁祸首往往是if/else嵌套。要减少if的使用，有很多办法：
- 优化代码结构，能少判断就少判断
- 使用switch
- 把多的缩进变成新函数
