-
Notifications
You must be signed in to change notification settings - Fork 10
/
phpcs.xml.dist
65 lines (53 loc) · 2.12 KB
/
phpcs.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
<?xml version="1.0"?>
<ruleset name="WordPress LH">
<description>Some additional rule settings for development at Luehrsen // Heinrich</description>
<rule ref="PHPCompatibility"/>
<!-- Sets the minimum supported WP version to 5.5, which is over a year old. -->
<config name="minimum_supported_wp_version" value="5.5" />
<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"/>
<!-- For CI, don't fail on warnings -->
<config name="ignore_warnings_on_exit" value="1"/>
<!-- Track our build folder -->
<file>./build</file>
<!-- Our Textdomain for i18n -->
<rule ref="WordPress.WP.I18n">
<properties>
<property name="text_domain" value="quicklink" />
</properties>
</rule>
<!-- Sometimes we need to override globals -->
<rule ref="WordPress.WP.GlobalVariablesOverride.OverrideProhibited">
<type>warning</type>
</rule>
<!-- Make missing translator comment a warning. -->
<rule ref="WordPress.WP.I18n.MissingTranslatorsComment">
<type>warning</type>
</rule>
<!--
Prevent errors caused by WordPress Coding Standards not supporting PHP 8.0+.
See https://github.com/WordPress/WordPress-Coding-Standards/issues/2035
-->
<ini name="error_reporting" value="E_ALL & ~E_DEPRECATED" />
<!-- Add an override ruleset to create config with higher hierachy -->
<rule ref="phpcs.override.xml"/>
</ruleset>