AEM Code Review Checklist

Description - As per development process, AEM Developers start work on an user story of AEM projects and after implementation they raise a pull request in GIT tool and code goes for review to assigned reviewer. Reviewers should be following some guidelines/instructions to ensure code quality.

Following are standard checklist should be covered during AEM code review.

- Check all HTML, JS and sass/scss file name matches as per business requirements.

  (sass stands for syntactically awesome style sheets)

- Check that JS and sass/scss file name should be the same as component name.

- Check the JS/sass/scss file path to match the path exactly as HTML.

- Check that we have all CSS hooks added to the HTML tags. This will be helpful to the
content platform team for setting up the look and feel of the component.

- Check that all HTML Tag Elements follow the semantics.

- Check that there are any CSS files committed? Only sass/scss files should be committed.
- Check that the sass/scss file css follow the structure.

- Check for the proper spacing in .sass/scss file. E.g. 

Width: 20px is the right format. Wrong one - width:20px

- Check that all test cases are added to have good code coverage.

- Check that is there any files committed which developers haven't modified to the feature
branch e.g. code, compiled files (.dir, MANIFEST.MF)

- Compare the code in DIFF for your changes (Git)

- Always do the rebase with develop branch (exceptionally if Sprint branch different than the
develop, rebase can be done with Sprint branch)

- Check for the commit message - should be relevant for the commit

- Check for title while raising the PR in git. It should be Feature\<user story> and give the
proper description for the PR

- Check comment to the new method created for proper description, Param, Return values. 

- Check for the blank line between description and Param or Return

- Check for the blank lines in the code and remove those

- Check for the formatted src/test Java Class Files

- Check for the formatted JavaScript/CSS Files

- Check for the formatted XML content.xml Files

- Check for the categories property having underscores in the clientlib file or not.

should use ‘-’ Hyphen

e.g.Right format: test.responsive-iframe. Wrong format: test.resonsive_iframe

- Check camelCase naming convention while naming component, dialog node and files.
- Check for the component title which should be in proper case format e.g. Third Party Form

- Check for proper jcr:description

- Check for Dialog title, description e.g. 

Title = Hide Thumbnail

description = Please use proper description in this case format.

- Check for the proper comment for Sightly e.g. It should start from line 1

<!--/*

<Component Description>

_______________________

<Component Name>

*/-->

- Check for the Placeholder in Sightly. It should follow syntax mentioned below.

<sly data-sly-test.isNotAuthored="${wcmmode.edit && !(properties.heading)}">

  <div class="cq-placeholder" data-emptytext="Component Name"></div>

</sly>

- Check for Placeholder in HTML, which should driven by hasContent method in Java/javabean

- Check for Sightly commenting style. Do not use JSP or HTML styling

- Check for the JSTL TAG in Sightly. Do not use them.

- Check for unnecessary declared variable in Sightly, instead use them directly.

- Check for the bean created for the Sightly. Do not use java methods directly in Sightly.
- Check for unnecessary unwrapping in Sightly. Do not use them for each line DIV should

wrap the below elements.

- Check that data-sly-test on parent tag or not. if data-sly-test not met condition, then
unwanted html tags should not be rendered having blank values

- Check if variables are declared in groups e.g. all Public variables declared in a group and
separated with blank line for Private variable

- Check that there is no file deleted in the existing code/function to add new code/function in
any Java, Junit, JS, CSS, Sightly files

- Check that template code is used or not. if code is reusable in multiple components
e.g. Heading, Image, Anchor tags, SVG Images etc.

- Check for the @Ignore notation in Junit. If it is to ignore Junit test case then remove the test

- Check, PR/Commit doesn’t include the code, which is not modified by the developers.