O código é escrito uma vez, mas lido muitas vezes. Gastar algum tempo antes para limpar o código que escrevemos vai pagar dividendos pela estrada, já que nós e outros desenvolvedores precisamos lê-lo mais tarde.
O ideal é que outro programador não tenha que abrir um módulo para entender o que ele faz. Do mesmo modo, eles deveriam ser capazes de dizer o que um método faz sem lê-lo. Quanto melhor pudermos assinar essas ideias, mais fácil será a leitura de nosso código e mais rápido seremos capazes de escrever e mudar nosso código.
Várias implementações de uma interface são chamadas de <Variant><Interface>, ou seja, JcrReader e FileSystemReader.
Os pacotes são nomeados como com.adobe.product.module. Cada artefato Maven ou pacote OSGi deve ter seu próprio pacote.
Observe que essas convenções não precisam necessariamente ser aplicadas às implementações do cliente, mas é importante que as convenções sejam definidas e aplicadas para que o código possa permanecer preservável.
O ideal é que os nomes revelem a sua intenção. Um teste de código comum para quando os nomes não são tão claros quanto deveriam ser é a presença de comentários explicando para que serve a variável ou o método:
DRY indica que o mesmo conjunto de códigos nunca deve ser duplicado. Isso também se aplica a coisas como literais de cordas. A duplicação de código abre a porta para defeitos sempre que algo tem que mudar e deve ser procurado e eliminado.
As regras de CSS devem ser específicas ao seu elemento de público alvo no contexto do aplicativo. Por exemplo, uma regra CSS aplicada a .content.center seria excessivamente ampla e poderia potencialmente causar impacto em muitos conteúdos em todo o sistema, exigindo que outras pessoas substituíssem esse estilo no futuro. .myapp- centertextseria uma regra mais específica, pois está especificando ** texto centralizado no contexto do aplicativo.
Quando uma API está obsoleta, é sempre melhor encontrar a nova abordagem recomendada em vez de depender da API obsoleta. Isso garantirá upgrades mais suaves no futuro.
Quaisquer strings que não estejam sendo fornecidas por um autor devem ser vinculadas em uma chamada para o dicionário i18n do AEM por meio de I18n.get() em JSP/Java e CQ.I18n.get() no JavaScript. Essa implementação retornará a sequência de caracteres transmitida a ela se nenhuma implementação for encontrada, portanto, isso oferta a flexibilidade de implementar a localização após implementar os recursos no idioma principal.