Suggerimenti per la codifica

Usare il più possibile taglibs o HTL

L'inclusione di script in JSP rende difficile il debug dei problemi nel codice. Inoltre, includendo gli script in JSP, è difficile separare la logica aziendale dal livello di visualizzazione, che è una violazione del principio di responsabilità singola e del modello di progettazione MVC.

Codice leggibile in scrittura

Il codice viene scritto una volta, ma letto più volte. Trascorrere un po 'di tempo in avanti per pulire il codice che scriviamo pagherà i dividendi lungo la strada come noi e altri sviluppatori hanno bisogno di leggerlo più tardi.

Scegliere i nomi di rivelazione delle intenzioni

Idealmente, un altro programmatore non dovrebbe dover aprire un modulo per capire cosa fa. Allo stesso modo, dovrebbero essere in grado di capire cosa fa un metodo senza leggerlo. Meglio possiamo abbonarci a queste idee, più facile sarà leggere il nostro codice e più velocemente saremo in grado di scrivere e cambiare il nostro codice.

Nella base di codici AEM sono utilizzate le seguenti convenzioni:

• Un'unica implementazione di un'interfaccia è denominata <Interface>Impl, ovvero ReaderImpl.
• Più implementazioni di un'interfaccia sono denominate <Variant><Interface>, ovvero JcrReader e FileSystemReader.
• Le classi di base astratte sono denominate Abstract<Interface> o Abstract<Variant><Interface>.
• I pacchetti sono denominati com.adobe.product.module. Ogni manufatto Maven o bundle OSGi deve avere un proprio pacchetto.
• Le implementazioni Java vengono inserite in un pacchetto impl sotto la relativa API.

Tenete presente che queste convenzioni non devono necessariamente essere applicate alle implementazioni dei clienti, ma è importante che le convenzioni siano definite e rispettate in modo che il codice possa essere mantenuto.

Idealmente, i nomi dovrebbero rivelare le loro intenzioni. Un test comune del codice per i nomi che non sono chiari come dovrebbero essere è la presenza di commenti che spiegano a cosa serve la variabile o il metodo:

Non ripetere

DRY afferma che lo stesso set di codici non deve mai essere duplicato. Questo vale anche per cose come i letterali stringa. La duplicazione del codice apre la porta a difetti ogni volta che qualcosa deve cambiare e deve essere ricercato ed eliminato.

Evitare regole CSS nude

Le regole CSS devono essere specifiche per l'elemento di destinazione nel contesto dell'applicazione. Ad esempio, una regola CSS applicata a .content.center sarebbe troppo ampia e potrebbe potenzialmente avere un impatto su un sacco di contenuto nel sistema, richiedendo ad altri di ignorare questo stile in futuro. .myapp- centertextè una regola più specifica in quanto specifica il ** testo centrato nel contesto dell'applicazione.

Eliminazione dell'utilizzo di API obsolete

Quando un'API è obsoleta, è sempre meglio trovare il nuovo approccio consigliato invece di affidarsi all'API obsoleta. In questo modo, gli aggiornamenti saranno più fluidi in futuro.

Scrivi codice localizzabile

Le stringhe che non vengono fornite da un autore devono essere racchiuse in una chiamata al dizionario i18n di AEM tramite I18n.get() in JSP/Java e CQ.I18n.get() in JavaScript. Questa implementazione restituirà la stringa che gli è stata passata se non viene trovata alcuna implementazione, quindi offre la flessibilità di implementare la localizzazione dopo l'implementazione delle funzionalità nella lingua primaria.

Escape resource path for security

Mentre i percorsi nel JCR non devono contenere spazi, la loro presenza non deve causare l'interruzione del codice. Jackrabbit fornisce una classe di utilità Testo con i metodi escape() e escapePath(). Per i JSP, l'interfaccia Granite espone una funzione granite:encodeURIPath() EL.

Utilizzate l'API XSS e/o l'HTL per proteggere dagli attacchi di script tra siti

AEM fornisce un'API XSS per pulire facilmente i parametri e garantire la sicurezza dagli attacchi di script tra siti. Inoltre, HTL ha queste protezioni integrate direttamente nel linguaggio di modellazione. Un foglio di supporto API è disponibile per il download all'indirizzo Sviluppo - Linee guida e best practice.

Implementare la registrazione appropriata

Per il codice Java, AEM supporta slf4j come API standard per la registrazione dei messaggi e dovrebbe essere utilizzato insieme alle configurazioni rese disponibili tramite la console OSGi per garantire la coerenza dell'amministrazione. Slf4j espone cinque diversi livelli di registrazione. Per scegliere quale livello registrare un messaggio, consigliamo di utilizzare le seguenti linee guida:

• ERRORE: Quando un elemento è danneggiato nel codice e l'elaborazione non può continuare. Ciò si verificherà spesso a seguito di un'eccezione imprevista. In genere è utile includere tracce di stack in questi scenari.
• AVVISO: Quando qualcosa non funziona correttamente, ma l'elaborazione può continuare. Spesso questo è il risultato di un'eccezione prevista, ad esempio PathNotFoundException.
• INFORMAZIONI: Informazioni utili per il monitoraggio di un sistema. Tieni presente che questa è l'impostazione predefinita e che la maggior parte dei clienti lascerà tale impostazione agli ambienti. Pertanto, non utilizzarla eccessivamente.
• DEBUG: Informazioni di livello inferiore sull'elaborazione. Utile quando si esegue il debug di un problema con il supporto.
• TRACE: Le informazioni di livello più basso, ad esempio i metodi di immissione/uscita. In genere questo viene utilizzato solo dagli sviluppatori.

Nel caso di JavaScript, console.log deve essere utilizzato solo durante lo sviluppo e tutte le istruzioni di registro devono essere rimosse prima del rilascio.

Evitare la programmazione di cult cargo

Evitate di copiare il codice senza comprendere cosa fa. In caso di dubbi, è sempre meglio chiedere a qualcuno che ha più esperienza con il modulo o l'API su cui non si è chiari.