關於寫代碼的幾個看法
最近在新公司負責bug的修復，發現很多的代碼邏輯理解起來有些困難。現在將其中觀察到的現象列出來，談談自己的看法。
1.類過大
對於代碼來說，我們在編寫的時候最好做到SRP(Single Responsibility Principle)。但是實際的項目由於經過了不同的開發人員，以及工期比較緊張的原因，所以這一原則被遵守的不是很好。經常看到一個函數100多行，可能我遇到的還算好的了，這個問題不是最大的。
修改建議:一個函數最好控制在30--50行左右
2.同樣的一種情況，用多個變量表示
比如說對於視頻格式，HLS(m3u8)有時候叫hls，有時候叫m3u8,這個問題還好，然後一個bool的變量代表hls(hlsType_),一個代表m3u8(m3u8Type_).判斷的時候有時候用hlsType_,有時候用m3u8Type_,導致判斷變量不明確。一個地方忘記修改，就非常容易出現bug。
修改建議:對於一個類型，只用一種標誌，判斷方式最好由函數導出而不是直接判斷變量類型。
3.在函數的參數中，引入bool類型的控制變量
在函數中引入bool變量被成為邏輯耦合，這對於代碼的理解是非常不好的。
具體的分析 https://coolshell.cn/articles/5444.html 。記得代碼中有個函數是這樣的
void Func(Client& client,bool dns,bool complete).表示智商不好的我，問了好多次領導終弄明白了，就趕快加上了註釋。
能猜出來dns和complete的含義和關系的同學，我向你們表示敬意。
修改建議:不在函數中寫入bool變量。
4.數據傳輸和業務邏輯未分離
對於網絡編程來說，主要涉及到兩個部分。1.socket IO和2.協議解析 其實這兩個部分是正交的，舉個例子說明一下。
比如 “乾隆” 讓 “和大人” 到宮裏商量事情,用的是兩個人只懂的暗號，這就是協議。
這個消息怎麽讓“和大人”知道就是socket IO。
比如協議可以選擇 1.滿文 2.漢文 或者 3.詩詞中的一些話。
傳輸方式可以選擇 1.口諭 2.聖旨 3.信鴿 。
可以形成一個組合型的矩陣。
| 協議 | 滿文 | 漢文 |
|---|---|---|
| 口諭 | 滿文口諭 | 漢文口諭 |
| 信鴿 | 信鴿帶滿文紙條 | 信鴿帶漢文紙條 |
這樣的設計在擴充協議或者傳輸方式的時候都非常的容易，而且每個部分各司其職，非常容易理解。
修改建議:將協議解析和數據傳輸分開，容易理解。
5.減少類的成員變量，相關變量合並和註釋
在很多的代碼規範中，會提到盡量少用或者不用全局變量，對於類來說，就是盡量減少類的成員變量，能用局部變量或者函數參數的方式表示的，盡量不要選擇用成員變量來表示。在對於需要一些計算結果的情況下，要做到不要邊接受數據，邊計算中間結果。因為如果要對最後的結果進行修正的話，中間結果也需要修正，會增加程序的修改位置和難度。
修改建議:只保留數據的原始結果，在最後的步驟中計算最後的結果。
類的成員變量==類函數的全局變量
關於寫代碼的幾個看法