Tipps zum Programmieren

So oft wie möglich TagLibs oder HTL verwenden

Das Einschließen von Scriptlets in JSPs erschwert das Debugging von Fehlern im Code. Durch die Einbeziehung von Skripten in JSPs ist es außerdem schwierig, Geschäftslogik und Ansicht von der Ebene zu trennen, was eine Verletzung des Prinzips "Einfache Verantwortung"und des MVC-Designmusters darstellt.

Lesbaren Code schreiben

Code wird einmal geschrieben, aber viele Male gelesen. Wenn wir etwas Zeit vorn für die Bereinigung des Codes aufwenden, den wir schreiben, werden Dividenden auf der Straße ausgezahlt, wie wir und andere Entwickler es später lesen müssen.

Namen wählen, die den Zweck beschreiben

Idealerweise sollte ein anderer Programmierer kein Modul öffnen müssen, um zu verstehen, was es tut. Ebenso sollten sie in der Lage sein, zu erkennen, was eine Methode tut, ohne sie zu lesen. Je besser wir diese Ideen abonnieren können, desto leichter wird es sein, unseren Code zu lesen und desto schneller können wir unseren Code schreiben und ändern.

Für AEM-Codes gelten die folgenden Konventionen:

  • A single implementation of an interface is named <Interface>Impl, i.e. ReaderImpl.
  • Multiple implementations of an interface are named <Variant><Interface>, i.e. JcrReader and FileSystemReader.
  • Abstrakte Basisklassen werden benannt Abstract<Interface> oder Abstract<Variant><Interface>.
  • Packages are named com.adobe.product.module. Jedes Maven Artefakt- oder OSGi-Bundle muss ein eigenes Paket haben.
  • Java-Implementierungen werden in einem impl-Paket unter ihrer API platziert.

Beachten Sie, dass diese Konventionen nicht notwendigerweise für Kundenimplementierungen gelten müssen. Es ist jedoch wichtig, dass Konventionen definiert und eingehalten werden, sodass der Code verwaltbar bleibt.

Idealerweise sollten Namen den Zweck beschreiben. Ein üblicher Code-Test für den Fall, dass Namen nicht so eindeutig sind, wie sie sein sollten, besteht darin, dass Kommentare vorhanden sind, die erklären, wofür die Variable oder Methode verwendet wird:

Unklar

Clear

int d; /elapsed time in days

int elapsedTimeInDays;

/get tagged images
public List getItems() {}

public List getTaggedImages() {}

Wiederholungen vermeiden

Dieses Prinzip sieht vor, dass derselbe Codesatz niemals dupliziert werden sollte. Dies gilt auch für Dinge wie Zeichenfolgenliterale. Codeduplizierung öffnet die Tür für Defekte, wenn etwas geändert werden muss und sollte gesucht und beseitigt werden.

Blanke CSS-Regeln vermeiden

CSS-Regeln sollten speziell auf das Zielelement im Kontext Ihrer Anwendung ausgerichtet sein. For example, a CSS rule applied to .content .center would be overly broad and could potentially end up impacting lots of content across your system, requiring others to override this style in the future. .myapp-centerText wäre eine spezifischere Regel, da es zentrierten Text im Kontext Ihrer Anwendung angibt.

Verwendung veralteter APIs vermeiden

Wenn eine API veraltet ist, ist es besser, den neuen empfohlenen Ansatz zu suchen anstatt die veraltete API zu verwenden. Dadurch werden in Zukunft reibungslosere Upgrades sichergestellt.

Lokalisierbaren Code schreiben

Alle Strings, die nicht von einem Autor bereitgestellt werden, sollten in einem Aufruf des i18n-Wörterbuchs von AEM über I18n.get() in JSP/Java und CQ.I18n.get() in JavaScript zusammengefasst werden. Diese Implementierung gibt die Zeichenfolge zurück, die an sie übergeben wurde, wenn keine Implementierung gefunden wurde. Auf diese Weise wird die Flexibilität bei der Implementierung der lokale Anpassung nach der Implementierung der Funktionen in der Hauptsprache Angebot.

Ressourcenpfade zur Sicherheit maskieren

Zwar sollten Pfade im JCR keine Leerzeichen enthalten, aber der Code sollte nicht fehlschlagen, wenn Leerzeichen vorhanden sind. Jackrabbit stellt eine Text-Hilfsklasse mit den Methoden escape() und escapePath() bereit. For JSPs, Granite UI exposes a granite:encodeURIPath() EL function.

Zur Absicherung vor Cross-Site-Scripting-Angriffen die XSS-API und/oder HTL nutzen

AEM stellt eine XSS-API bereit, mit der Sie Parameter einfach bereinigen und die Absicherung vor Cross-Site-Scripting-Angriffen gewährleisten können. Zusätzlich hat HTL diese Schutzmechanismen direkt in die Vorlagensprache integriert. An API cheat sheet is available for download at Development - Guidelines and Best Practices.

Angemessene Protokollierung implementieren

Für Java-Code unterstützt AEM slf4j als Standard-API für die Protokollierung von Meldungen. Für eine konsistente Administration sollte die API in Verbindung mit den Konfigurationen genutzt werden, die über die OSGi-Konsole verfügbar sind. Slf4j umfasst fünf verschiedene Protokollierungsebenen. Wir empfehlen, bei der Auswahl der Ebene, auf der eine Meldung protokolliert werden soll, die folgenden Richtlinien anzuwenden:

  • ERROR: Wenn etwas im Code nicht funktioniert und die Verarbeitung nicht fortgesetzt werden kann. Dies geschieht oft aufgrund einer unerwarteten Ausnahme. In der Regel ist es hilfreich, Stapelspuren in diese Szenarien einzubeziehen.
  • WARN: Wenn etwas nicht richtig funktioniert hat, aber die Verarbeitung fortgesetzt werden kann. This will often be the result of an exception that we expected, such as a PathNotFoundException.
  • INFO: Informationen, die bei der Überwachung eines Systems hilfreich sein dürften. Denken Sie daran, dass dies der Standard ist und dass die meisten Kunden dies auf ihren Umgebung beibehalten werden. Verwenden Sie diese Ebene daher nicht zu häufig.
  • DEBUG: Informationen der unteren Ebene zur Verarbeitung. Hilfreich, wenn ein Problem zusammen mit dem Support behoben wird.
  • TRACE: Die niedrigste Ebene von Informationen, z. B. das Aufrufen/Beenden von Methoden. Dies wird in der Regel nur von Entwicklern verwendet.

Bei JavaScript sollte console.log nur während der Entwicklung genutzt werden und alle Protokollaussagen sollten vor der Veröffentlichung entfernt werden.

Nicht durchdachte Programmierung vermeiden

Vermeiden Sie es, Code zu kopieren, ohne zu wissen, was er tut. Im Zweifelsfall ist es immer am besten, jemanden zu fragen, der über mehr Erfahrung mit dem Modul oder der API verfügt, auf dem Sie nicht klar sind.

Auf dieser Seite