每個優秀程序員都應遵循的代碼原則和規范


本文由葡萄城技術團隊原創並首發

轉載請注明出處:葡萄城官網,葡萄城為開發者提供專業的開發工具、解決方案和服務,賦能開發者。

 

什么是優秀的程序員?

首先我們會先提出這個問題,如果你向10個人問這個問題,盡管可能答案不同,但是少有一點應該是一致的。而對我個人而言,一個優秀的程序員應該是一個能夠充分理解需求,並能提出可行性解決方案通過團隊協作向最終用戶展示成果。而說到團隊協作,就涉及到代碼的可維護性,那么你該如何管理龐大的代碼庫?如果放任團隊成員提交隨意的代碼,那么在項目中無論在bug修復還是新增功能,都將很難完成。

如果想要實現可維護這個目標,那么團隊中的每個成員都應該保證提交整潔且可維護的代碼。那么您應該讓你的團隊成員遵守一定的編碼原則。遵守這些原則,可以使你和其他人的協作變得更容易。所以團隊成員應該遵循什么樣的規則呢?

童子軍原則

童子軍是美國社會針對未成年人的一種教育實踐制度,加入童子軍的小朋友都要學習並遵守一些規則,然后獲得各種各樣的勛章。其中一條規則是離開宿營地前進行清掃活動的原則,簡潔明了:

Leave the campground cleaner than you found it.

假設某個小朋友來到某個宿營地,不幸發現地上有兩處垃圾,然后他自己在接下來的日常活動中也制造了一處垃圾。那么當他離開時,不僅要清理掉自己的垃圾,還要處理早先小朋友留下的兩處垃圾。應把注意力放在為下一個露營者創造更好的環境,而不是去尋找是誰丟的。

這個原則放到軟件生產中則意味着讓check in比check out時更整潔,至少不要讓代碼變得更糟糕。

(圖片來源於網絡)

避免重復

盡量在項目的開發過程中減少產出重復的代碼、方法和類,多數的設計模式根本目的是為了減少代碼重復,盡可能將重復使用的代碼抽象封裝,是提高代碼的可重用性和可維護性的最佳方式之一。

功能獨立

這里功能獨立的意思是指,函數或方法盡可能簡單,功能盡可能獨立。

換句話來講就是,一個方法最好只做一件事,如果你覺得你的代碼過於復雜,該怎么做?抽方法。

初級程序員最常犯的錯誤就是在一個方法中包含了很多種要做的工作,這可能會在軟件的生命周期帶來災難。

簡單易懂的代碼比“聰明“的代碼更好

程序員作為社會中最聰明的群體之一,往往在寫代碼時也會產出一些炫技的代碼塊,這部分代碼塊過段時間再去看,就像謎一樣存在於程序中,雖然很簡潔,但並不易讀。

例如:有些人在程序中喜歡使用三目運算而非if-else,雖然本身使用三目運算符沒有問題,但存在嵌套情況時,那么對於后面的維護者就是一場噩夢,例如如下代碼:

(A>B?(A>C?A:C):(B>C?B:C))

其實上面的代碼等同於,顯然下面的格式更易懂

if(A>B){
    (A>C?A:C)
}else{
    (B>C?B:C)
}

迪米特法則

迪米特法則是1987年秋天由lan holland在美國東北大學一個叫做迪米特的項目設計提出的,它要求一個對象應該對其他對象有最少的了解,所以迪米特法則又叫做最少知識原則。它的意義旨在降低類和類之間的耦合,避免發生由於耦合度過大造成的因為一個類發生變化,而對另一個類造成影響。

YAGNI

YAGNI原則是指在開發時只需要將應用程序必需的功能包含進來,而不要試圖添加任何其他你認為可能需要的功能。開發過程中為了應對將來可能的提出的需求,提前開發一些功能進去,我們通常會花不少時間成本在這些過度設計的功能開發上,但可能未來的兩三年內這個設計根本沒有用到。應把更多的精力花在更重要的功能開發上,適度假設未來需求的規划,加速后期功能迭代和代碼維護。

總結

雖然上面提了很多原則和規范,但這些規范需要在長期在工作中的實踐才能有更深的理解的。希望您能從本文中了解一些基礎,最后,希望大家都能寫出優美、規范的代碼。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM