優秀的程序員會用盡量簡單的方式來解釋他們的代碼,即便是物理學家均可以用一張白紙和一隻鉛筆來解釋蟲洞,咱們又未嘗不可?ios
我會盡量讓代碼寫地簡單、易讀,包括選擇合適的變量名、使用編碼規範(code conventions)等等,但仍是缺了點東西,理解代碼不該該是去理解「如何」實現的,而是要理解想要「達成」什麼。程序員
甚至能夠說要讓讀代碼像讀小說同樣,而不是一大堆代碼。ide
下面討論三大主題:函數
閱讀其餘人的代碼可能會很是折磨,若是不提供合適的上下文,咱們會迷失在尋找某個函數或屬性的意義中。佈局
不管是二進制語言、低級語言仍是高級語言,語法都在變得愈來愈友好,以便吸引更多開發者。而隨着語法變得更接近英語,咱們的代碼也應該簡明扼要、不言自明。學習
寫出良好的代碼,讀起來像小說同樣,容易閱讀和理解(即便沒有給出上下文)。編碼
其實作爲一個ios開發者,有一個學習的氛圍跟一個交流圈子特別重要,這是一個個人iOS (扣扣)交流圈代理
681503716 (驗證碼:寂靜)code
無論你是小白仍是大牛歡迎入駐,你們一塊兒交流學習orm
正確的方式是:
咱們寫函數時都會假設閱讀它的人擁有足夠的上下文,可以理解函數想實現什麼。用模糊的含義來命名函數,例如「handleRedView()」會引發不少問題,」RedView」是啥?這個函數主要是想幹啥?
因此在某些狀況下函數的用途會很模糊,若是沒有提供足夠的上下文,閱讀起來會很是困難
咱們能夠把函數的用途分爲四類:
通知(Informer)函數
管理(Management)函數
路由(Router)函數
執行(Execution)函數
一般會觸發路由/管理函數,例子以下:
回調函數,通知某事已經/即將發生,並給機會進行響應。
大部分狀況下用於被代理(delegate)觸發的操做,或是通知(notification)處理函數。
用於聯合多個函數以實現更高級的用途,不須要依賴參數,block 中的全部代碼都會執行。
上面的函數包含全部須要的信息,汽車啓動時執行這些函數,此時咱們不關注這是「如何」實現的,而是關注它作了「什麼」
用於聯合多個函數以實現更高級的用途,須要依賴一些參數,只在咱們想執行的時候才執行。
路由函數一般同於指向執行函數,但在某些狀況下,若是邏輯代碼不超過一行,也能夠包含本身的邏輯。
函數名字的具體實現。
這樣就能寫出一個乾淨、簡短的類,可讀性強,容易維護。
避免在函數名稱裏使用」and「: playAndMinimize() loadAndPlay() 這個壞習慣會打破單一責任原則,寫出可以適應兩種狀況的代碼。
避免在函數名稱裏進行猜想:moveRedViewIfNeeded()上面的例子會致使後面的程序員必須深刻此函數,才能理解觸發移動 Red View 的時機,這樣不夠清晰。
不,layoutIfNeeded() 並不屬於這種狀況,由於咱們知道若是某個 view 的 setNeedDisplay 爲 true,就應該從新佈局。這種狀況在 Swift 語言裏很廣泛,由於函數基本上都是應用私有的。
談及代碼可讀性,我首先會想到編碼規範(code convention),它們被廣泛接受、應用普遍,但使用編碼規範並不必定會提高代碼質量,雖然有跨應用性但可讀性更差。
」is「前綴應該用於布爾型變量和方法,以便解釋返回值是布爾類型的。#編碼規範
既然」if「語句老是用於布爾值,那還有必要給每一個布爾屬性都加上」is「嗎?爲何蘋果要把 Swift 語法從 view.hidden 改爲 view.isHidden?我只能想到一種答案……由於「if view.isHidden」看起來更天然。
嘗試以如下原則使用「is」前綴:
若是類的某個布爾屬性/方法用於該類(公開)的實例,就有正當理由使用「is」前綴
若是布爾屬性在類內部(私有)使用,前綴就是多餘的。
若是布爾型屬性/方法同時被私有和公開使用,那麼應該用計算屬性來返回該私有屬性值。
雖然用私有 set 並公開使用該屬性也是能夠的,但上面這種方式能夠實現封裝(encapsulation)。
封裝用於隱藏類中結構化數據對象的值或狀態,防止未受權方直接訪問。
那若是不是本身直接處理的布爾型,若是如何命名呢?
private var playerIsPlaying: Bool
private var gridConstraintIsEnabled()
「is」 須要指向某個東西:view.isHidden, 「is」指向 view。上面的例子裏使用了此原則,playerIsPlaying,「is」指向 player。
/if playerIsPlaying { }/ 對比 /if isPlayerIsPlaying {}/哪一個更天然?我想你已經有答案了。