歡迎光臨
每天分享高質量文章

代碼不規範,同事兩行淚,擼碼七宗罪!

作者:Nitin Sharma
譯者:羅昭成
原文:hackernoon.com/the-7-deadly-sins-of-programming-a7574efc639f
出自:blog.csdn.net/csdnnews/article/details/87706176


編程江湖中一直盛傳著一個段子,那就是要問程式員最討厭哪 4 件事?那必須是:寫註釋、寫文件、別人不寫註釋、別人不寫文件。

更甚者,在《流浪地球》形成刷屏之勢之後,仿其而出的“代碼千萬行,註釋第一行;編程不規範,同事兩行淚”在技術圈中開始盛傳,由此可見對於所有的程式員來說這是多麼痛苦的事情。

本文作者 —— 全棧開發者 Nitin Sharma 分享了編程的七宗罪,也許對你會有所啟發。

以下為譯文:

還有什麼事情比自己動手去創造更有趣?看著你發明的東西慢慢地進入生活?我們人類,是萬物之主,是造物主。

但是在數字化時代,發明創造的方式發生了變化。現在,我們都創造數字化產品。我們建網站、寫軟體來滿足我們的需求。雖然我們創造不再依賴於我們的創造力,但是我們仍然可以與藝術家其名。

編程的世界非常地寬廣,涉及重多領域,我們有很多選擇。你可以選擇使用函式式編程,還是使用面向物件編程?你可以選擇做服務端還是客戶端?那麼,你心中已經有抉擇了嗎?下麵,有 100 種編程語言,可以用來實現你的需求。

語言、框架、庫都在逐漸增多。你可以通過多種方式完成相同的代碼功能。雖然這些語言可能差別很大,但是大多數語言都遵循相同的思想。所以,他們也會出現相同的問題。

以下是編程七宗罪,你可以想辦法避免他們發生。雖然我不是基督教徒,但是我也喜歡定義七宗罪。

協作時不使用版本控制

上帝保佑,我們有版本控制工具。如我所說,如果我們沒有像 Git 這種版本管理工具,代碼的世界將變得異常艱難。版本控制讓我們在協作的時候,修改或移動變得非常簡單。

想像一下,我們坐在電腦前,手動檢查併合並檔案,為不同的版本儲存不同的檔案夾。這樣做是非常低效的,並且很不可靠。幸運的是,我們有 Git 和其它版本控制工具,來幫我們完成這個事情。

我參與過沒有版本控制的專案,那簡直就是一場惡夢。

不使用合適的變數命名

我不知道為什麼,身邊總有一些人,使用很短/隨機的名稱來給變數命名。當你的專案只有 10-20 行代碼,或者只是代碼片段時,你可以使用這種方式進行命名,但是在大專案中,不要這麼做。不合適的命名,對可讀性和效率有致命的影響。

一個命名的簡單規則:你變數的名稱可以自解釋。當你看到它們的時候,就知道他們的用途。但是不要使用太長的名字來命名!保持命名簡短,並具有可讀性。

讓我們來找一找,你的代碼中用 a , b, c 命名的代碼。

使用過多的依賴,不經思考直接升級

GitHub 上面有多少個開源專案? 已經多到我們數不清了。這些開源庫使開發者的工作變得更加容易,節約我們的時間。

但是使用過多的依賴庫會對整個專案帶來風險。依賴庫越多,就意味著編譯時間和運行時間的加長。我們應該在我們需要的地方添加對應的依賴庫,而不要為了使用它而使用它。

所以,在升級之前,我們需要經常去檢查依賴庫/插件的支持情況。我曾經有一次,升級了 React,而沒有去檢查它對其它庫的影響。到如今,我依然認為這是我生命中最嚴重的錯誤之一。

不自解釋的代碼

值得一提的是,沒有人想閱讀整個方法/檔案來理解它是乾什麼用的。使用最少的代碼來實現功能,但是不要讓別人或者是以後的自己,討厭你自己寫的東西。

我們應該一直嘗試去寫自解釋的代碼。我們應該讓我們的代碼,在第一次被看到的時候,就知道它是乾什麼用的。要完成這樣的代碼,我們需要進行正確的代碼重構,統一的語法,適當的變數名稱。必要的時候,還要給代碼添加註釋。

當然,也不要過多地書寫註釋,你不需要通過註釋解釋每一行代碼。最好用 1-2 行註釋,寫清楚重要部分的概述或說明。

格式不一致

這個和第四點非常相近,格式不一致也會對可讀性和生產效率帶來巨大的影響。在專案中,選擇一個特定的命名規範並一直堅持下去,不要在中途改變它們。我個人更喜歡用大寫字母來命名檔案,駝峰命名法來命名方法、變數等。但這些也會根據不同的語言而作出改變。

沒有比開發者格式化代碼更糟糕的事情。

此外,在代碼中,我們還需要使用相同的縮進格式。根據你的代碼樣式和選擇的語言,使用 2/4/8 個空格來做縮進。但無論你使用什麼樣的格式,請堅持在整個專案中一直使用。

不處理錯誤

畏懼它。逃避它。Bug 終會降臨! —— 滅霸(譯者註:指 Bug 如影隨形,不休不止,像詛咒一樣。)

事情是這樣的,無論你是多麼優秀的程式員,你的代碼都有可能會出現問題,除非你寫的是像如下的這種代碼:

  1. console.log("Yey")
  2. printf("Wow")

這些錯誤有可能是因為 API 錯誤引起的,也有可能是超時,型別錯誤,空值,或者只有上帝知道的原因。通常,這些會讓你的代碼出現問題。

在不同的語言中,處理錯誤的方式有很大的差異。但是一般情況下,在訪問資料之前都需要判斷資料否為空。在我的經驗中,空指標比其它錯誤都多。

所以,在執行資料處理的相關需求時,建議將代碼放到 try-catch 中,並處理對應的異常,最後,不要忘記告訴用戶哪裡出現了問題。如果在用戶按下按鈕和按鍵的時候不給用戶反饋,用戶將不知道發生了什麼。給用戶錯誤提示,並告訴它下一步怎麼做。

時刻記住滅霸的話。

使用不當的資料型別/資料結構

在不同的語言中,資料型別要求不一樣,強型別語言非常嚴格,而弱型別可以隨意使用。強型別語言在編譯時就會告訴你錯誤,而其它語言需要在運行時,才能知道錯誤。

舉個例子,我們將數值儲存在整型/符點型/雙精度符點型的變數中,並且與儲存在字串中的變數進行比較時,有的語言會進行自動型別轉換,然後進行比較,而有的語言並不會。

結語

編程七宗罪,讓人不爽。我們需要避免出現。

這個僅僅是在編程中出現的常見錯誤。你很難看到,一個程式員,在他的程式中出現這些問題。但這也正如聖經中的七宗罪一樣,不僅是這些問題。它們是原罪,可以組合成不同的錯誤。

你認為還有什麼錯誤需要加在這個串列裡面,在評論中寫出來,讓我知道。

Happy Coding!

    赞(0)

    分享創造快樂