WordCamp Notes: Leverage Linting To Be A Better Developer - Matt Vanderpol
code quality tool
4 main components
1. the code
2. rules - describe what the code should look like when everything is working well
3. process - a program that runs, pulls in the rules, analyzes the code, figures out where it does NOT match the rules
4. reports - when the process is done, you need a way to see the output, where your code does not match, where the problems are that you need to address
helps you catch bugs
can enforce best practices — how code should be organized, how things should be spaced, etc.
ensures consistency from developer to developer, project to project
can help when you’ve been away from a project, coming back to it after months/years, this helps you reengage with it more easily
when doing a code review, the review can focus on the QUALITY not the FORMAT of the code.
the overall process —
starts w/ code
you get a report, tells you where the errors are, you fix them
and this goes around in a circle
where does linting fit into your process/flow?
needs to be triggered somewhere
in yr editor, on a particular keystroke, command, etc
using a task runner - can add linting as a step here
pre-commit hook to prevent un-linted code from being committed to Git
continuos integration - if someone tries to merge code that doesn’t pass linting, it can be rejected
do what makes the most sense for your project.
no “one true way” to do it.
2. code quality
formatting - essentially cosmetic. how code should look, where spaces go, etc
quality - how long function name should be, where documentation should go, etc.
rules can be affected/moderated by in-line comments/config
special comments by file, block, line
in real world situations, you might need to go around the rules
linters need the rules to do anything
they’re what the program evaluates to check yr code
predefined rulesets, linters come with
generally these are best practices for that language / industry
great starting point
you may find as you go on, you have some special needs for yr code, don’t want to exactly follow what they predefined. you can customize these, use plugins, add additional rules, etc.
show you where the problems are in yr code
where there are infractions that the linting process has found
3 things in a report
1. location - which file, line number and column number where the problem exists
2. severity - how bad is this problem? error or warning.
can mix / match at different configs.
something is a warning in your editor but an error in a pre-commit hook so nothing gets added to the repo until it’s fixed
3. rule - can include more details on why something broke, more info, why this code broke, how to make it pass, etc.
the linter can fix some problems automatically
mainly for code formatting issues.
-- fix commandline option
prettier (standalone tool, mainly for front-end stuff) fairly opinionated about how code should be formatted
stylelint - node based, really fast
scss-lint - ruby based, a little sluggish
some plugins you can integrate to modify how this works and better suit yr workflow
“rules” section of config
always use lowercase values for hex, indentation, etc
.eslintrc config file
not as verbose as stylelint’s config file is
PHP_CodeSniffer - linter for php
ruleset for WordPress
PSR - ruleset for modern php devs, outside of WordPress
need to make a decision when you start about which one you’ll use
config file is an XML file
report gives line numbers for errors but not which column the error is on
rule names are a little more verbose in this linter
first thing you should do
run an “initial lint”, see what breaks, what you’re facing in order to add linting to the project
this is a great time to add autofix, clean up the low hanging fruit so you don’t have to deal with it manually
then run the linter again
now you see the stuff that’s NOT an easy fix
can sit down w/ the team -
decide if we’ll ignore certain files,
ignore specific rules in some files (and configure with in-line config via the linter)
make sure you are linting any NEW code
so however you exclude old code, just be sure that the NEW code doesn’t get skipped as well
other resources -
PHPCS 101 Videos (on YouTube)
ScreamingFist sample theme
other stuff —
not linting but similar. let’s you define a config that many editors will read.
this can be a way for different people on the team write code in various editors, but have consistent formatting, etc.
PHPMD / PHP Depend
Static code analysis tools
unit testing for PHP
defacto unit testing for PHP world