分析一套源代碼的代碼規範和風格並討論如何改進優化代碼

　　本次做業要求是分析一套源代碼的代碼規範和風格並討論如何改進優化代碼（結合工程實踐），上一次做業中，我選的軟件就有你們耳熟能詳的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語言編程規範，並選擇其中部分列於其上。