Skip to content

Commit 402fb90

Browse files
author
Robert Sösemann
authored
Replaced Rules list with a link to PMD site
1 parent 523fc13 commit 402fb90

File tree

1 file changed

+2
-38
lines changed

1 file changed

+2
-38
lines changed

README.md

Lines changed: 2 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -12,45 +12,9 @@ The engine and [all of](https://github.com/forcedotcom/idecore/tree/b5bf3a1cb6e8
1212
**[What we check](#rules) | [How to configure](#configuration) | [How to contribute](#contribute)**
1313

1414

15-
### <a name="rules">What issues are (currently) recognized?</a>
15+
### <a name="rules">What issues are recognized?</a>
1616

17-
18-
We currently check Apex classes and triggers for the following issues. Those could be easily ported from [existing PMD Java rules](http://pmd.sourceforge.net/snapshot/pmd-java/rules/) and fully applied to Apex. As this engine and its components are open-source everybody can contribute new or improved rules.
19-
20-
- **ExcessiveClassLength:** Long Class files are indications that the class may be trying to do too much. Try to break it down, and reduce the size to something manageable.
21-
22-
- **ExcessiveParameterList:** Methods with numerous parameters are a challenge to maintain, especially if most of them share thesame datatype. These situations usually denote the need for new objects to wrap the numerous parameters.
23-
ExcessiveClassLength: Excessive class file lengths are usually indications that the class may be burdened with excessive responsibilities that could be provided by external classes or functions. In breaking these methodsapart the code becomes more managable and ripe for reuse.
24-
25-
- **ExcessivePublicCount:** Classes with large numbers of public methods and attributes require disproportionate testing effortssince combinational side effects grow rapidly and increase risk. Refactoring these classes intosmaller ones not only increases testability and reliability but also allows new variations to bedeveloped easily.
26-
27-
- **StdCyclomaticComplexity:** Complexity directly affects maintenance costs is determined by the number of decision points in a method plus one for the method entry. The decision points include ‘if’, ‘while’, ‘for’, and ‘case labels’ calls. Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denotehigh complexity, and 11+ is very high complexity.
28-
29-
- **NcssMethodCount:** This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of linesof code for a given method. NCSS ignores comments, and counts actual statements. Using this algorithm,lines of code that are split are counted as one.
30-
31-
- **NcssTypeCount:** This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of linesof code for a given type. NCSS ignores comments, and counts actual statements. Using this algorithm,lines of code that are split are counted as one.
32-
33-
- **NcssConstructorCount:** This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of linesof code for a given constructor. NCSS ignores comments, and counts actual statements. Using this algorithm,lines of code that are split are counted as one.
34-
35-
- **TooManyFields:** Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields,possibly through grouping related fields in new objects. For example, a class with individual city/state/zip fields could park them within a single Address field.
36-
37-
- **AvoidDeeplyNestedIfStmts:** Avoid creating deeply nested if-then statements since they are harder to read and error-prone to maintain.
38-
39-
- **AvoidSoqlInLoops:** New objects created within loops should be checked to see if they can created outside them and reused.
40-
41-
- **AvoidLogicInTrigger:** As triggers do not allow methods like regular classes they are less flexible and suited to apply good encapsulation style. Therefore delegate the triggers work to a regular class (often called Trigger handler class). See more here: [Apex Trigger Best Practices](https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices)
42-
43-
- **AvoidGlobalModifier:** Global classes should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.Many interfaces (e.g. Batch) required global modifiers in the past but don’t require this anymore. Don’t look yourself in.
44-
45-
- **ClassNamingConventions:** Class names should always begin with an upper case character.
46-
47-
- **MethodNamingConventions:** Method names should always begin with a lower case character, and should not contain underscores.
48-
49-
- **MethodWithSameNameAsEnclosingClass:** Non-constructor methods should not have the same name as the enclosing class.
50-
51-
- **VariableNamingConventions:** A variable naming conventions rule - customize this to your liking. Currently, it checks for final variables that should be fully capitalized and non-final variables that should not include underscores.
52-
53-
See here for a more [detailed description of the Apex rules](http://pmd.sourceforge.net/snapshot/pmd-apex/rules/index.html).
17+
**[List of all 29 PMD rules for Apex..](http://pmd.sourceforge.net/snapshot/pmd-apex/rules/index.html)**
5418

5519
### <a name="configuration">Enable and configure the Engine</a>
5620

0 commit comments

Comments
 (0)