Always have filenames in backticks

Author: jrfnl

wiki/Annotated-Ruleset.md

@@ -1,4 +1,4 @@
-PHP_CodeSniffer allows developers to design their own coding standards by creating a simple ruleset XML file that both pulls in sniffs from existing standards and customises them for the developer's needs. This XML file can be named anything you like, as long as it has an `xml` extension and complies to the ruleset.xml format. The file can be stored anywhere, making it perfect for placing under version control with a project's source code and unit tests.
+PHP_CodeSniffer allows developers to design their own coding standards by creating a simple ruleset XML file that both pulls in sniffs from existing standards and customises them for the developer's needs. This XML file can be named anything you like, as long as it has an `xml` extension and complies to the `ruleset.xml` format. The file can be stored anywhere, making it perfect for placing under version control with a project's source code and unit tests.
 
 Once created, a ruleset file can be used with the `--standard` command line argument. In the following example, PHP_CodeSniffer will use the coding standard defined in a custom ruleset file called `custom_ruleset.xml`:
 

wiki/Coding-Standard-Tutorial.md

@@ -44,7 +44,7 @@ The content of the `ruleset.xml` file should, at a minimum, be the following:
 ```
 
 > [!NOTE]
-> The ruleset.xml can be left quite small, as it is in this example coding standard. For information about the other features that the `ruleset.xml` provides, see the [[Annotated ruleset]].
+> The `ruleset.xml` can be left quite small, as it is in this example coding standard. For information about the other features that the `ruleset.xml` provides, see the [[Annotated ruleset]].
 
 ## Creating the Sniff
 

wiki/Customisable-Sniff-Properties.md

@@ -1,4 +1,4 @@
-The behaviour of some sniffs can be changed by setting certain sniff properties in your ruleset.xml file. This page lists the sniff properties that are available for customisation. For properties that were added after ruleset support was introduced in version 1.3.0, the first stable version that made the property available is listed.
+The behaviour of some sniffs can be changed by setting certain sniff properties in your `ruleset.xml` file. This page lists the sniff properties that are available for customisation. For properties that were added after ruleset support was introduced in version 1.3.0, the first stable version that made the property available is listed.
 
 For more information about changing sniff behaviour by customising your ruleset, see the [[Annotated ruleset]].
 

wiki/Version-3.0-Upgrade-Guide.md

@@ -1,7 +1,7 @@
 PHP_CodeSniffer version 3 contains a large number of core changes and breaks backwards compatibility for all custom sniffs and reports. The aim of this guide is to help developers upgrade their custom sniffs, unit tests, and reports from PHP_CodeSniffer version 2 to version 3.
 
 > [!NOTE]
-> If you only use the built-in coding standards, or you have a custom ruleset.xml file that only makes use of the sniffs and reports distributed with PHP_CodeSniffer, you do not need to make any changes to begin using PHP_CodeSniffer version 3.
+> If you only use the built-in coding standards, or you have a custom `ruleset.xml` file that only makes use of the sniffs and reports distributed with PHP_CodeSniffer, you do not need to make any changes to begin using PHP_CodeSniffer version 3.
 
 ***
 
@@ -19,7 +19,7 @@ All sniffs must now be namespaced.
 > [!NOTE]
 > It doesn't matter what namespace you use for your sniffs as long as the last part of the namespace is in the format `StandardName\Sniffs\Category` as this is used to determine the sniff code. The examples below use a very minimal namespace but you can prefix it with whatever makes sense for your project. If you aren't sure what namespace to use, try using the example format.
 >
-> If you decide to use a more complex prefix, or your prefix does not match the name of the directory containing your ruleset.xml file, you need to define the prefix in the ruleset tag of your ruleset.xml file. For example, if your namespace format for sniffs is `MyProject\CS\StandardName\Sniffs\Category`, set the namespace to `MyProject\CS\StandardName` (everything up to `\Sniffs\`). The ruleset tag would look like this: `<ruleset name="Custom Standard" namespace="MyProject\CS\StandardName">`
+> If you decide to use a more complex prefix, or your prefix does not match the name of the directory containing your `ruleset.xml` file, you need to define the prefix in the ruleset tag of your `ruleset.xml` file. For example, if your namespace format for sniffs is `MyProject\CS\StandardName\Sniffs\Category`, set the namespace to `MyProject\CS\StandardName` (everything up to `\Sniffs\`). The ruleset tag would look like this: `<ruleset name="Custom Standard" namespace="MyProject\CS\StandardName">`
 
 Internal namespace changes to core classes require changes to all sniff class definitions. The old definition looked like this:
 ```php

wiki/Version-4.0-Developer-Upgrade-Guide.md

@@ -43,7 +43,7 @@ If your userbase is known to often combine multiple external standards, making t
 The vast majority of the below upgrade tasks will need to be executed in both cases, but there are some upgrade tasks which can only be executed once support for PHP_CodeSniffer 3.x is being dropped.
 
 
-## Upgrading the ruleset.xml file
+## Upgrading the `ruleset.xml` file
 
 See the [[Upgrade Guide for Ruleset Maintainers and End-Users|Version 4.0 User Upgrade Guide]] for everything you need to know about upgrading the `ruleset.xml` file.