Het opnemen van scriptlets in JSPs maakt het moeilijk om kwesties in de code te zuiveren. Bovendien, door scriptlets in JSPs op te nemen, is het moeilijk om bedrijfslogica van de meningslaag te scheiden, die een schending van het Enige Verantwoordelijkheidsbeginsel en het ontwerppatroon MVC vormt.
Code wordt één keer geschreven, maar vaak gelezen. Als we enige tijd op voorhand besteden aan het opschonen van de code die we schrijven, zullen we dividend uitbetalen over de weg, terwijl we en andere ontwikkelaars het later moeten lezen.
Idealiter hoeft een andere programmeur geen module te openen om te begrijpen wat deze doet. Ze moeten ook kunnen zien wat een methode doet zonder deze te lezen. Hoe beter we ons kunnen abonneren op deze ideeën, hoe gemakkelijker het is om onze code te lezen en hoe sneller we onze code kunnen schrijven en wijzigen.
In de basis van de AEM code worden de volgende conventies gebruikt:
<Interface>Impl
, d.w.z. ReaderImpl
.<Variant><Interface>
, d.w.z. JcrReader
en FileSystemReader
.Abstract<Interface>
of Abstract<Variant><Interface>
.com.adobe.product.module
. Elke Maven-artefact- of OSGi-bundel moet een eigen pakket hebben.Deze conventies hoeven niet noodzakelijkerwijs van toepassing te zijn op de implementaties van de klant, maar het is belangrijk dat conventies worden gedefinieerd en nageleefd, zodat de code behouden kan blijven.
In het ideale geval zouden namen hun intentie moeten onthullen. Een gemeenschappelijke codetest voor wanneer de namen niet zo duidelijk zijn aangezien zij zouden moeten zijn de aanwezigheid van commentaren die verklaren wat de variabele of de methode voor zijn:
Onduidelijk |
Wissen |
int d; //verstreken tijd in dagen |
int elapsedTimeInDays; |
//get getagde afbeeldingen |
public List getTaggedImages() {} |
DRY geeft aan dat dezelfde codeset nooit mag worden gedupliceerd. Dit geldt ook voor zaken als letterlijke tekenreeksen. Codeduplicatie opent de deur voor defecten wanneer iets moet veranderen en moet worden gezocht en geëlimineerd.
CSS-regels moeten specifiek zijn voor uw doelelement in de context van uw toepassing. Een CSS-regel die bijvoorbeeld op .content.center wordt toegepast, zou te breed zijn en zou mogelijk veel inhoud op uw systeem beïnvloeden, waardoor anderen deze stijl in de toekomst moeten overschrijven. .mijnapp- centertext zou een specifiekere regel moeten zijn aangezien het gecentreerde ** tekst in de context van uw toepassing specificeert.
Wanneer een API wordt afgekeurd, is het altijd beter om de nieuwe geadviseerde benadering te vinden in plaats van het vertrouwen op afgekeurde API. Hierdoor zijn upgrades in de toekomst vloeiender.
Tekenreeksen die niet door een auteur worden verschaft, moeten worden opgenomen in een aanroep van het i18n-woordenboek van AEM via I18n.get() in JSP/Java en CQ.I18n.get() in JavaScript. Deze implementatie retourneert de tekenreeks die eraan is doorgegeven als er geen implementatie wordt gevonden. Dit biedt dus de flexibiliteit om lokalisatie te implementeren nadat de functies in de primaire taal zijn geïmplementeerd.
Paden in het JCR mogen geen spaties bevatten, maar de aanwezigheid ervan mag er niet toe leiden dat code wordt afgebroken. Jackrabbit biedt een hulpprogramma Text met de methoden escape() en escapePath(). Voor JSPs, stelt granite UI een granite:encodeURIPath() EL functie bloot.
AEM verstrekt een XSS API om parameters gemakkelijk schoon te maken en veiligheid van dwars-plaats scripting aanvallen te verzekeren. Bovendien heeft HTL deze beschermingen direct in de sjabloontaal ingebouwd. Een API bedriegblad is beschikbaar voor download bij Ontwikkeling - Richtlijnen en Beste praktijken.
Voor code Java, AEM steunt slf4j als standaard API voor het registreren van berichten en zou samen met de configuraties moeten worden gebruikt die door de console OSGi voor consistentie in beleid ter beschikking worden gesteld. Slf4j stelt vijf verschillende registrerenniveaus bloot. Wij adviseren gebruikend de volgende richtlijnen wanneer het kiezen welk niveau om een bericht bij te registreren:
In het geval van JavaScript, console.log zou slechts tijdens ontwikkeling moeten worden gebruikt en alle logboekverklaringen zouden vóór versie moeten worden verwijderd.
Vermijd het kopiëren van code zonder te begrijpen wat het doet. In geval van twijfel is het altijd beter om iemand te vragen die meer ervaring heeft met de module of API waarop u niet duidelijk bent.