分析一套源代码的代码规范和风格并讨论如何改进优化代码

　　本次做业要求是分析一套源代码的代码规范和风格并讨论如何改进优化代码（结合工程实践），上一次做业中，我选的软件就有你们耳熟能详的B站（哔哩哔哩），恰巧前一阵子B站源代码泄露，我有幸搞到了一份。所以本文以B站源代码做为对象进行分析。

1.目录及代码

　　B站是用GO写的，下边贴上其代码目录；

能够看到在目录上对于各个包的命名是很清晰的，都对应了各个模块的功能，并且简洁精炼。

下边单独看其中一个代码片断：

 

此处是两段不一样功能的service;首先看到的是代码是赏心悦目的，可读性很强，相应的注释也有。相应的变量命名如error 还有ok等都遵循了简短而又能代表变量含义的规则。

固然了，通篇代码的注释虽然有，实际上是不多的，对于后来人的维护可能会有一点困难。

若是可以将每一段的功能和大体的逻辑用只言片语标注下，相信代码的可读性回有很大的改观。

2.下边总结GO语言的代码风格和通常规范：

1.package命名应该尽量的简短而且全部字母都应该是小写，例如
package chubby
2.receiver命名最多2个字母，不能使用me或者self或者this，例如
func (c *Client) GetUserName() string
3.每行代码长度最好不超过80个字符，若是超过建议换行
4.函数参数定义
　　1）参数类型不是map,slice或者chan须要采用传"指针"类型而不是传"值"类型，例如
　　func (s *Service) Login(args *loginArgs) error {}
　　2）参数类型是map,slice或者chan，不要用指针传递
5.函数返回值采用返回"指针"类型而不是返回"值"类型
6.错误处理的原则是不能忽略任何error，不要使用"_"丢弃，必须所有处理
接收到错误，要么返回error给上层调用，要么使用log打印对应的error和warn信息
7.log信息应该输出"[fileName - function]"前缀，在排查问题的时候可以快速定位到出问题的代码
8.强烈建议不要乱抛panic，由于panic会致使进程crash
9.任何一个goroutine都应该有recover来保护程序不会由于panic而crash，由于任何一个goroutine若是抛panic但没有recover整个程序会crash
10.业务逻辑函数须要把每一个步骤耗时打印出来，有助于分析排查问题

对于GO语言不是特别熟悉，以上通常规范参考了网络上各个GO语言编程规范，并选择其中部分列于其上。