JSP中包含指令碼,使得在程式碼中對問題進行除錯變得困難。 另外,由於JSP中包含了指令碼,很難將業務邏輯與視圖層分離,這違反了單責原則和MVC設計模式。
程式碼只寫一次,但讀了很多次。 在前面花些時間清理我們編寫的代碼,會在將來支付紅利,因為我們和其他開發商需要稍後讀它。
理想情況下,另一個程式設計師不應該開啟一個模組來了解它的作用。 同樣,他們應該能夠在不閱讀方法的情況下分辨方法的作用。 訂閱這些想法越好,閱讀代碼就越容易,編寫和更改代碼的速度就越快。
在AEM程式碼基底中,會使用下列慣例:
<Interface>Impl
,即ReaderImpl
。<Variant><Interface>
,即JcrReader
和FileSystemReader
。Abstract<Interface>
或Abstract<Variant><Interface>
。com.adobe.product.module
。 每個Maven工件或OSGi捆綁包必須有其自己的包。請注意,這些慣例不一定需要套用至客戶實作,但請務必定義並遵守慣例,讓程式碼可持續維護。
理想情況下,名字應該顯示其意圖。 當名稱不如應有的清楚時,常見的程式碼測試是是否有說明變數或方法用途的註解:
不明 |
清除 |
int d;//間隔天數 |
int elapsedTimeInDays; |
//get標籤的影像 |
public list getTaggedImages(){} |
DRY指出,同一組程式碼絕不應重複。 這也適用於字串文字之類的項目。 每當有東西需要改變,需要尋找並消除時,代碼重複就會開啟缺陷的大門。
CSS規則應該是應用程式內容中您的目標元素專屬。 例如,套用至.content .center的CSS規則會過於廣泛,並可能最終影響您系統中的許多內容,要求其他人在未來覆寫此樣式。 .myapp-centertext twtw將是更具體的規則,因為它會在應用程式的 ** 內容中指定居中文字。
API遭取代時,最好找到新建議的方法,而非依賴已遭取代的API。 這將確保將來更順利的升級。
作者未提供的任何字串,都應透過JSP/Java中的I18n.get()以及JavaScript中的CQ.I18n.get(),包裝在對AEM i18n字典的呼叫中。 如果找不到實作,此實作會傳回傳遞至它的字串,因此在以主要語言實作功能後,這可提供實作本地化的彈性。
JCR中的路徑不應包含空格,但若路徑存在,則不應導致程式碼中斷。 Jackrabbit提供了一個Text實用程式類,該類具有escape()和escapePath()方法。 若是JSP,Granite UI會公開granite:encodeURIPath()EL函式。
AEM提供XSS API,可輕鬆清除參數,並確保免受跨網站指令碼攻擊的安全性。 此外,HTL也直接在範本語言中內建這些保護功能。 如需下載API速查表,請前往Development - Guidelines and Best Practices。
針對Java程式碼,AEM支援slf4j作為記錄訊息的標準API,且應與透過OSGi主控台提供的設定搭配使用,以便在管理上保持一致。 Slf4j會公開五個不同的記錄層級。 選擇要記錄訊息的層級時,建議您使用下列准則:
若是JavaScript,console.log僅應在開發期間使用,且所有記錄陳述式應在發行前移除。
若不了解程式碼的功能,請避免復製程式碼。 有疑問時,最好詢問對您不清楚的模組或API有更多經驗的人。