Repository files navigation

ApexMetrics is aCode Climate engine for the programming languageApex of theSalesforce.com cloud platform.

If youconnect your Github repositories to Code Climate and enable the Enginestatic code analysis is performed on every commit or pull request. The resulting continuous metrics will tell you where code improved or degraded over time and whichhot spots need refactoring.

The engine andall ofits "ingredients" are open-source so everybody in the community can contribute. The engine was built by a software engineers atUp2Go who struggled with enforcing Clean Code into their daily work giventhe lack of metrics tools in the Salesforce.com ecosystem. Not to forget theawesome supportbymanyothers.

What we check |How to configure |How to contribute

50+ rules for Apex and Visualforce..

Code Climate will not run this engine on your code unless you have this minimal '.codeclimate.yml' (Note the leading dot) in the root directory of your repository.

engines:apexmetrics:enabled:trueratings:paths:    -"**.cls"    -"**.trigger"    -"**.page"    -"**.component"

For more details about Code Climate configuration go todocs.codeclimate.com.

To exclude single files or folders from the analysis add aexclude_paths section to the file like in this minimal example:

engines:apexmetrics:enabled:trueratings:paths:    -"**.cls"    -"**.trigger"exclude_paths:  -"/src/triggers"  -"**.xml"

We recommend you to adapt a copy of this.codeclimate.yml which already excludes most of the irrelevant Salesforce.com files and folders.

For more details about how to exclude files and folders go todocs.codeclimate.com.

Not all checks make sense under all circumstances so configurability is crucial when it comes to Code metrix. By adjusting your.codeclimate.yml you can eighter disable certain checksfor a single issue orfor your whole repo.

But that's not enough. One key benefit of Code Climate is grading. Grading not only takes the amount of issues into a account but also how severe issues are to fix. To customize if and when code is marked as issue you need to go "one level deeper". The static code analysis performed by this engine usesan Apex port of thefamous Java tool PMD. PMD is very flexible and can beconfigured using a so called ruleset xml file.

By default or engine uses thisapex-ruleset.xml. It enables all rules and runs them with values we came up with as good defaults. Just add a copy of that file to the root directory of your repository and adapt it to your needs.

<ruleref="rulesets/apex/complexity.xml/ExcessiveClassLength"message="Avoid really long classes (lines of code)">  <priority>3</priority>  <properties><!-- Rule specific property defining, when a class is marked as too long-->    <propertyname="minimum"value="1000"/><!-- Code Climate specific properties-->    <propertyname="cc_remediation_points_multiplier"value="150"/>    <propertyname="cc_categories"value="Complexity"/>    <propertyname="cc_block_highlighting"value="false"/>  </properties></rule>

Some rules have parameters which define if and when code is marked as issue. To learn how such parameters influence a check go to the readup section of an issue which describs

All properties starting withcc_ are Code Climate specific and define how the results are displayed or how grades are calculated.

• cc_remediation_points_multiplier: This is multiplication factor for the Code Climate Remediation Point default of 50.000. To understand the semantics and importance of Remediation point please check thedocs.codeclimate.com.
• cc_categories: The Code Climate specificcategorization. Might differ from PMD.
• cc_block_highlighting: Defaults to 'false'. Only the first line of a problematic block is highlighted in the UI. If set to 'true' the whole block is highlighted which currently looks ugly.

There is a lot of room for improvement or extension. Depending on what you want to do you eighter need to fork, extend and pull request this repository or the PMD repository. Please check theWiki to learn how to contribute.