是什么樣的步驟，使得你的ios代碼變得如此容易閱讀？大咖分享

優秀的程序員會用盡可能簡單的方式來解釋他們的代碼，即使是物理學家都可以用一張白紙和一只鉛筆來解釋蟲洞，我們又何嘗不可？

我會盡可能讓代碼寫地簡單、易讀，包括選擇合適的變量名、使用編碼規范（code conventions）等等，但還是缺了點東西，理解代碼不應該是去理解“如何”實現的，而是要理解想要“達成”什么。

甚至可以說要讓讀代碼像讀小說一樣，而不是一大堆代碼。

下面討論三大主題：

問題

閱讀其他人的代碼可能會非常折磨，如果不提供合適的上下文，我們會迷失在尋找某個函數或屬性的意義中。

建議

不論是二進制語言、低級語言還是高級語言，語法都在變得越來越友好，以便吸引更多開發者。而隨著語法變得更接近英語，我們的代碼也應該簡明扼要、不言自明。

結果

寫出良好的代碼，讀起來像小說一樣，容易閱讀和理解（即使沒有給出上下文）。

?其實做為一個ios開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS （扣扣）交流圈

681503716 (驗證碼：寂靜）

不管你是小白還是大牛歡迎入駐，大家一起交流學習

函數命名

正確的方式是：

我們寫函數時都會假設閱讀它的人擁有足夠的上下文，能夠理解函數想實現什么。用模糊的含義來命名函數，例如“handleRedView()”會引起很多問題，”RedView”是啥？這個函數主要是想干啥？

所以在某些情況下函數的用途會很模糊，如果沒有提供足夠的上下文，閱讀起來會非常困難

我們可以把函數的用途分為四類：

通知（Informer）函數
管理（Management）函數
路由（Router）函數
執行（Execution）函數

1. 通知函數

通常會觸發路由/管理函數，例子如下：

回調函數，通知某事已經/即將發生，并給機會進行響應。

大部分情況下用于被代理（delegate）觸發的操作，或是通知（notification）處理函數。

2. 管理函數

用于聯合多個函數以實現更高級的用途，不需要依賴參數，block 中的所有代碼都會執行。

上面的函數包含所有需要的信息，汽車啟動時執行這些函數，此時我們不關注這是“如何”實現的，而是關注它做了“什么”

3. 路由函數

用于聯合多個函數以實現更高級的用途，需要依賴一些參數，只在我們想執行的時候才執行。

路由函數通常同于指向執行函數，但在某些情況下，如果邏輯代碼不超過一行，也可以包含自己的邏輯。

4. 執行函數

函數名字的具體實現。

這樣就能寫出一個干凈、簡短的類，可讀性強，容易維護。

* 謹記一項原則，每個函數都應該只有一個責任。

避免在函數名稱里使用”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 {}/
哪個更自然？我想你已經有答案了。