代碼的壞味道

代碼首先是寫給人看的，只是恰巧（incidentally）可以運行。 ----Paul Graham 如今寫C++服務後端，工做內容大部分是推薦系統後臺開發。推薦系統算是公司技術架構中比較基礎服務的模塊，因此對代碼質量的要求比較高。以前作遊戲不少時候代碼都是趕工的，也沒有很好的靜下來思考去重構，幾天沒事重構了以前的一個模塊，重構後，代碼可讀性有了很大提高。 咱們都知道要追求高質量的代碼，什麼是高質量的代碼，這個標準就比較高了，但咱們須要至少保證不寫出很難維護的代碼。平時每次的pr都須要被經理review，本身寫代碼的要求愈來愈高。

代碼的壞味道體如今： ####1.註釋太多或者太少 整個代碼都是不少的註釋，整個屏幕沒幾行是代碼的，想要看個整個代碼還須要翻好幾頁，可以維護你的代碼的人，能力都是和你比較接近的，別人還不是那麼蠢。 每一個人負責的功能仍是有一點的不一樣，有時候的確遇到一些功能，實現起來比較曲折，若是不是本身寫的別人很難理解錯誤，這時候須要額外註釋一下，利於後來人的維護。 ####2.代碼風格不統一 這個通常出如今新人的代碼中，好比匈牙利命名和駝峯命名法交叉使用，看起來就讓人厭惡，代碼風格總體必須保持統一，總體看起來不那麼亂。

std::vector<int64_t> gid_list;
std::vector<int>  uidList;

####3.函數命名 看一段代碼，首先看到的是代碼的函數名，好的代碼，一看函數名就知道函數的做用，爛的代碼，函數名字模棱兩可，讓人只能去讀函數的每一行代碼才能讀懂。

bool check(int64_t gid);       //1
bool avaliable(int64_t gid); //goods

對於一些檢測函數，以確定的語句更合適。 ####4.變量命名 初學者常常容易用t1,t2,t3等以字母加數字組合的方式來命名。變量命寧願長點也不要過短。 好比要保存itemcf推薦的物品gid列表。

std::vector<int64_t> gids;        //1
std::vector<int64_t> itemcf_gids;  //goods

i，j，k通常僅用於for循環中的下標。推薦換爲具體的下表定義單詞。 ####5.代碼一行字符太多 有的函數聲明就好長的一行，要看完還得須要移動光標到最後，繼續日後翻，這種看了就不想看，通常不要超過80字符，有些不可避免的過長，換行而後第二行插兩個tab對齊。

####6.函數體函數太長 一個函數體表明瞭一個模塊的封裝，若是函數的實現太長，有的甚至一屏幕都看不完，這時候你是否是須要考慮你的模塊劃分的有問題了，通常來講函數體平均不要超過50行，對於模塊進行正確的劃分。徹底可以減小函數的行數，使得函數實現更清晰明瞭。 ####7.重複的代碼 在實現功能的時候，徹底只考慮怎麼實現邏輯，徹底沒去想結構的調整，重複的邏輯出現了好幾回，代碼塊看起來臃腫不堪，須要很大力氣才能讀懂。 面向對象的繼承，多態，封裝這些的出現都是爲了解決代碼複用的問題，對於重複的邏輯徹底能夠將重複的功能提煉出來，封裝成一個函數，再去調用。 ####8.錯誤的設計 原本能夠有的更簡潔的實現，被實現的過於繁瑣，讓人看起來囉裏囉嗦，打個簡單的比方，須要保存一個列表，列表裏每一個元素只能惟一，若是被設計用vector去實現，還須要本身每次push_back時還須要手動去查找，若是一開始用set來存儲，代碼就會簡潔不少。(這個例子貌似不大合適) ####9.缺少必定的抽象能力 主要體如今一個最初的一個簡單需求，後來提了更多的需求，到最後一個功能有了好多的變種實現，功能代碼很難複用，好比對於一個初期的推薦，最開始須要保存的數據只是物品信息表以及一些操做一個類ReposManger就夠了，後期可能須要用戶的瀏覽記錄，心願單，用戶畫像等，該類操做愈來愈多，須要管理的數據愈來愈龐大，架構都不敢隨便動。這個主要體如今項目組裏開發效率比較高的人，大量的業務開發工做致使沒作過多的思考，要體會到這個壞味道須要必定的經驗。

要消除這些代碼的壞味道，只有經過多寫，多思考，多看好的代碼！