- Start from scratch, no code (yet)
- No architectural decisions have been made (yet)
- No frameworks or library’s chosen (yet)
- No Code styles have been chosen
- List of requirements and timescales
- It could have a mixture of code styles
- It could have mixture of frameworks and library's
- The code could be out of date
- It could be using an older version of PHP
- Team members who advocated a coding style may no longer be on the team
- Low documentation
- Migrating from one code style to another
- Migrating from one framework to another
- Migrating from versions which us different code conventions
- Be aware of known style violations before the first deployment
- Gain visual feedback on what parts of code need adjusting before the first deployment.
- Spot potential future gotchas in coding conventions.
- Create a CI that reports code violations quickly and blocks the pipeline from going forward.
- Ensure the team follows the same set of rules.
- Move quickly whilst ensuring the team comply with a given set of agreed coding conventions.
- Create a space for discussions about code conventions
- Be aware of known issues and violations in the project.
- Prioritise existing code smells
- Reduce team arguments on coding conventions.
- Make it easier for future developers to know which conventions are required.
- Ensure old code standards can be easily adapted.
- Remove old code styles (Either defined or implied)
- Minimise the amount of cross pollination of styles.
- PHPCS is just one of many tools
- Mess detection
- Compatibility checks
- Static analysis
- Tests (Unit/Integration/Acceptance)
- It forces code to adhere to a given set of rules (sniffs).
- It makes the code easier to read.
- It removes ambiguity of which convention is allowed.
- It reduces noise and debate in pull requests.
We read code more than we write code.
When we write code we read the surrounding code, the calling code and the architecture.
Switching between conventions is a brain drain.
A path to a directory or to a single file can be used.
If no output is shown then no errors have been recorded.
The report shows the line number, explanation of the error and file path.
The remaining column will list any errors that PHPCBF cannot fix.
- A sniff is a file checks one part of the coding standard.
- A coding standard is a collection of sniffs.
- A coding standard is a directory and a ruleset.xml
- The default standard is PEAR
- XML file of that configures the coding standard
- Can define include and exclude rules
- Can include output rules
- Can include sniffs from other rulesets
Includes LineLength sniff but changes settings so the sniff will show warnings for any line longer
than 90 chars and errors for any line longer than 100 chars.
Excludes the vendor directory
Excludes the vendor directory
Generator could be markdown
-p = Show progress of the run
-v = Print processed files
-d = Set the [key] php.ini value to [value] or [true] if value is omitted
--extensions = A comma separated list of file extensions to check
--parallel = Amount of processes to run
Example shows PHPCS ignoring line below.
Example shows PHPCS ignoring the current line.
Example shows PHPCS ignoring sniff
Run PHPCS first as this will require automatic alterations to the code
- Enforce that no code can be merged into the main branches unless the CI fully passes
- Don't check code that you haven't written.
- Don't include the vendor
- Ignore any code that is automatically generated like migrations
- Do not ignore lines, files or disable sniffs unless you really have to.
- Document why you are ignoring things.
- Choose to use PHPCS or PHP CS
- Investigate which conventions are currently in use
- Get an agreement with the team as to which conventions to use/drop
- If anything needs to be ignored then write a ticket and add the ticket reference into the comment.
- Collate all the ignored files, lines and have a meeting with the team to discuss a way forward.
- Can the ignored items be fixed and the rule be included
- Start very slowly with goal to get better linter over time
In the document include a brief explanation as to why you chose the standard and provide examples.
Give this document to new starters.
Pin this to slack, email it to the team and make sure everyone agrees.
Make it very obvious.