generated from luehrsenheinrich/wp-plugin-boilerplate
-
Notifications
You must be signed in to change notification settings - Fork 0
/
phpcs.xml
executable file
·48 lines (40 loc) · 1.53 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>
<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/vendor</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="wpmschema" />
</properties>
</rule>
<rule ref="WordPress.Files">
<exclude name="WordPress.Files.FileName"/>
</rule>
<!-- Add an override ruleset to create config with higher hierachy -->
<rule ref="phpcs.override.xml"/>
</ruleset>