-
Notifications
You must be signed in to change notification settings - Fork 1
/
phpmd.xml.dist
233 lines (194 loc) · 11.1 KB
/
phpmd.xml.dist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
<?xml version="1.0"?>
<ruleset name="MacFJA PHPMD ruleset"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
>
<description>Composition of standard PHPMD rules.</description>
<!-- Clean Code Rules: The Clean Code ruleset contains rules that enforce
a clean code base. This includes rules from SOLID and object
calisthenics. -->
<!-- <rule ref="rulesets/cleancode.xml"> -->
<!-- A boolean flag argument is a reliable indicator for a violation of
the Single Responsibility Principle (SRP). You can fix this
problem by extracting the logic in the boolean flag into its own
class or method. -->
<!-- <exclude name="BooleanArgumentFlag" /> -->
<!-- An if expression with an else branch is never necessary. You can
rewrite the conditions in a way that the else is not necessary and
the code becomes simpler to read. To achieve this use early return
statements. To achieve this you may need to split the code it
several smaller methods. For very simple assignments you could also
use the ternary operations. -->
<!-- <exclude name="ElseExpression" /> -->
<!-- Static access causes unexchangeable dependencies to other classes
and leads to hard to test code. Avoid using static access at all
costs and instead inject dependencies through the constructor. The
only case when static access is acceptable is when used for factory
methods. -->
<!-- <exclude name="StaticAccess" /> -->
<!-- </rule> -->
<!-- Code Size Rules: The Code Size Ruleset contains a collection of
rules that find code size related problems. -->
<rule ref="rulesets/codesize.xml">
<!-- Complexity is determined by the number of decision points in a
method plus one for the method entry. The decision points are 'if',
'while', 'for', and 'case labels'. Generally, 1-4 is low
complexity, 5-7 indicates moderate complexity, 8-10 is high
complexity, and 11+ is very high complexity. -->
<exclude name="CyclomaticComplexity" />
<!-- The NPath complexity of a method is the number of acyclic execution
paths through that method. A threshold of 200 is generally
considered the point where measures should be taken to reduce
complexity. -->
<exclude name="NPathComplexity" />
<!-- Violations of this rule usually indicate that the method is doing
too much. Try to reduce the method size by creating helper methods
and removing any copy/pasted code. -->
<exclude name="ExcessiveMethodLength" />
<!-- 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. -->
<exclude name="ExcessiveClassLength" />
<!-- Long parameter lists can indicate that a new object should be
created to wrap the numerous parameters. Basically, try to group
the parameters together. -->
<!-- <exclude name="ExcessiveParameterList" /> -->
<!-- A large number of public methods and attributes declared in a class
can indicate the class may need to be broken up as increased effort
will be required to thoroughly test it. -->
<!-- <exclude name="ExcessivePublicCount" /> -->
<!-- Classes that have too many fields could be redesigned to have fewer
fields, possibly through some nested object grouping of some of the
information. For example, a class with city/state/zip fields could
instead have one Address field. -->
<!-- <exclude name="TooManyFields" /> -->
<!-- A class with too many methods is probably a good suspect for
refactoring, in order to reduce its complexity and find a way to
have more fine grained objects. By default it ignores methods
starting with 'get' or 'set'. The default was changed from 10 to 25
in PHPMD 2.3. -->
<!-- <exclude name="TooManyMethods" /> -->
<!-- A class with too many public methods is probably a good suspect for
refactoring, in order to reduce its complexity and find a way to
have more fine grained objects. By default it ignores methods
starting with 'get' or 'set'. -->
<exclude name="TooManyPublicMethods" />
<!-- The Weighted Method Count (WMC) of a class is a good indicator of
how much time and effort is required to modify and maintain this
class. The WMC metric is defined as the sum of complexities of all
methods declared in a class. A large number of methods also means
that this class has a greater potential impact on derived classes.
-->
<!-- <exclude name="ExcessiveClassComplexity" /> -->
</rule>
<rule ref="rulesets/codesize.xml/ExcessiveMethodLength">
<properties>
<property name="ignore-whitespace" value="true" />
<property name="minimum" value="200" />
</properties>
</rule>
<rule ref="rulesets/codesize.xml/ExcessiveClassLength">
<properties>
<property name="ignore-whitespace" value="true" />
<property name="minimum" value="2000" />
</properties>
</rule>
<!-- Controversial Rules: This ruleset contains a collection of
controversial rules. -->
<rule ref="rulesets/controversial.xml">
<!-- Accessing a super-global variable directly is considered a bad
practice. These variables should be encapsulated in objects that
are provided by a framework, for instance. -->
<!-- <exclude name="Superglobals" /> -->
<!-- It is considered best practice to use the CamelCase notation to
name classes. -->
<!-- <exclude name="CamelCaseClassName" /> -->
<!-- It is considered best practice to use the camelCase notation to
name attributes. -->
<!-- <exclude name="CamelCasePropertyName" /> -->
<!-- It is considered best practice to use the camelCase notation to
name methods. -->
<!-- <exclude name="CamelCaseMethodName" /> -->
<!-- It is considered best practice to use the camelCase notation to
name parameters. -->
<!-- <exclude name="CamelCaseParameterName" /> -->
<!-- It is considered best practice to use the camelCase notation to
name variables. -->
<!-- <exclude name="CamelCaseVariableName" /> -->
</rule>
<!-- Design Rules: The Design Ruleset contains a collection of rules
that find software design related problems. -->
<rule ref="rulesets/design.xml">
<!-- An exit-expression within regular code is untestable and therefore
it should be avoided. Consider to move the exit-expression into
some kind of startup script where an error/exception code is
returned to the calling environment. -->
<!-- <exclude name="ExitExpression" /> -->
<!-- An eval-expression is untestable, a security risk and bad practice.
Therefore it should be avoided. Consider to replace the eval-
expression with regular code. -->
<!-- <exclude name="EvalExpression" /> -->
<!-- Goto makes code harder to read and it is nearly impossible to
understand the control flow of an application that uses this
language construct. Therefore it should be avoided. Consider to
replace Goto with regular control structures and separate
methods/function, which are easier to read. -->
<!-- <exclude name="GotoStatement" /> -->
<!-- A class with an excessive number of children is an indicator for an
unbalanced class hierarchy. You should consider to refactor this
class hierarchy. -->
<!-- <exclude name="NumberOfChildren" /> -->
<!-- A class with many parents is an indicator for an unbalanced and
wrong class hierarchy. You should consider to refactor this class
hierarchy. -->
<!-- <exclude name="DepthOfInheritance" /> -->
<!-- A class with too many dependencies has negative impacts on several
quality aspects of a class. This includes quality criteria like
stability, maintainability and understandability -->
<!-- <exclude name="CouplingBetweenObjects" /> -->
<!-- Functions like var_dump(), print_r() etc. are normally only used
during development and therefore such calls in production code are
a good indicator that they were just forgotten. -->
<!-- <exclude name="DevelopmentCodeFragment" /> -->
</rule>
<!-- Naming Rules: The Naming Ruleset contains a collection of rules
about names - too long, too short, and so forth. -->
<rule ref="rulesets/naming.xml">
<!-- Detects when a field, local, or parameter has a very short name.
-->
<!-- <exclude name="ShortVariable" /> -->
<!-- Detects when a field, formal or local variable is declared with a
long name. -->
<!-- <exclude name="LongVariable" /> -->
<!-- Detects when very short method names are used.
-->
<!-- <exclude name="ShortMethodName" /> -->
<!-- A constructor method should not have the same name as the enclosing
class, consider to use the PHP 5 __construct method. -->
<!-- <exclude name="ConstructorWithNameAsEnclosingClass" /> -->
<!-- Class/Interface constant names should always be defined in
uppercase. -->
<!-- <exclude name="ConstantNamingConventions" /> -->
<!-- Looks for methods named 'getX()' with 'boolean' as the return type.
The convention is to name these methods 'isX()' or 'hasX()'. -->
<!-- <exclude name="BooleanGetMethodName" /> -->
</rule>
<!-- Unused Code Rules: The Unused Code Ruleset contains a collection of
rules that find unused code. -->
<rule ref="rulesets/unusedcode.xml">
<!-- Detects when a private field is declared and/or assigned a value,
but not used. -->
<!-- <exclude name="UnusedPrivateField" /> -->
<!-- Detects when a local variable is declared and/or assigned, but not
used. -->
<!-- <exclude name="UnusedLocalVariable" /> -->
<!-- Unused Private Method detects when a private method is declared but
is unused. -->
<!-- <exclude name="UnusedPrivateMethod" /> -->
<!-- Avoid passing parameters to methods or constructors and then not
using those parameters. -->
<exclude name="UnusedFormalParameter" />
</rule>
</ruleset>