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

　　本次作业要求是分析一套源代码的代码规范和风格并讨论如何改进优化代码（结合工程实践），上一次作业中，我选的软件就有大家耳熟能详的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语言编程规范，并选择其中部分列于其上。