-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathphpcs.xml
executable file
·48 lines (41 loc) · 1.58 KB
/
phpcs.xml
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
<?xml version="1.0"?>
<ruleset name="WordPress LH">
<description>Some additional rule settings for development at Luehrsen // Heinrich</description>
<!-- Check for cross-version support for PHP 5.6 and higher. -->
<config name="testVersion" value="5.6-"/>
<rule ref="PHPCompatibilityWP"/>
<rule ref="WordPress-Core">
<!--
OK, real talk right now. Yoda conditions are ridiculous.
The fundamental problem that Yoda conditions attempts to solve is:
the equality operator is very close to the assignment operator.
It's easy to mess up and accidentally assign to the variable you're
trying to check.
Here's the thing though. Yoda conditions just don't read correctly
in the code flow. They require you to change the way you think
about the control flow.
Rather than forcing every conditional to be backwards, why not ban
assignment from conditionals? You never really *need* to assign in
a conditional.
So, here's where I stand: no to Yoda conditions. Yes to banning
assignment in conditionals.
Thank you Human Made!
-->
<exclude name="WordPress.PHP.YodaConditions" />
</rule>
<rule ref="WordPress-Docs"/>
<arg name="extensions" value="php"/>
<file>./build</file>
<exclude-pattern>./build/puc</exclude-pattern>
<exclude-pattern>./bin-php</exclude-pattern>
<!-- For CI, don't fail on warnings -->
<config name="ignore_warnings_on_exit" value="1"/>
<rule ref="WordPress.WP.I18n">
<properties>
<property name="text_domain" value="wpmyte" />
</properties>
</rule>
<rule ref="WordPress.Files">
<exclude name="WordPress.Files.FileName"/>
</rule>
</ruleset>