Android/Java 的編碼規範（Google）
怎麼才可以寫好一個程式，怎麼保證自己的程式碼的可讀性和可維護性？
Google的編碼規範為我們提供了檔案規範，檔案結構規範，格式規範，命名規範，程式設計規範，Javadoc的文件規範等等。
有了好的編碼規範後，我們發現在程式碼的命名，可讀性上發現有了質的提升，至少在表面上我們的程式碼可讀性獲得了成功。仔細閱讀程式碼，具體到內容的時候，我們又可能發現程式碼冗餘，程式碼耦合度過高，方法冗長等等的問題。那麼具體到編碼內容的時候，怎麼保證程式碼的可讀性和維護性呢？需要遵循什麼原則呢？
Java程式設計最基本的原則就是要追求高內聚和低耦合的解決方案和程式碼模組設計，需要遵循以下五個原則又叫SOLID原則：
| 原則簡寫 | 名稱 | 說明 |
|---|---|---|
| SRP | 單一責任原則 |
類或者方法責任或者功能單一： 一個類只只做一種型別的責任 一個方法只處理一個原子性的功能點 |
| OCP | 開放封閉原則 |
軟體實體應該是可擴充套件的而不是可修改的： 1.擴充套件功能時，通過增加程式碼而不是原有的程式碼 2.模組間通過介面來互動，客戶模組不用關心服務模組的型別修改。服務模組可方便地擴充套件功能，並且服務模組修改服務時，客戶模組不用有任何改動 |
| LSP | 里氏替換原則 |
子類能夠替換任何的父類例項 客戶模組不應關心服務模組的是如何工作的；同樣的介面模組之間，可以在不知道服務模組程式碼的情況下，進行替換。即介面或父類出現的地方，實現介面的類或子類可以代入。 |
| ISP | 介面分離原則 |
不能強迫實現類去依賴那些他們不使用的介面，如果出現，就將介面分離，使用多個專門的介面比使用單一的總介面總要好 |
| DIP | 依賴倒置原則 | 1. 高層模組不應該依賴於低層模組，二者都應該依賴於抽象 2. 抽象不應該依賴於細節，細節應該依賴於抽象 |
編碼原則的舉例，後續：
當我們有了好的程式碼規範和編碼原則的時候，這個時候我們編寫程式碼，設計模組都有據可循了。當然，每個人在執行規範和原則的時候會根據個人的理解水平的不同而不同，並且每個人在不同時期理解的程度也不一樣，多以我們在設計一個模組，一個功能，一個類，或者取一個名稱的時候如果主動的問下，這種設計是否遵循了規範，是否符合編碼的原則，好處在哪裡，後續怎麼維護的時候，時間久了相信也一定可以寫出優秀的框架級的程式碼。