WordCamp Notes: Leverage Linting To Be A Better Developer - Matt Vanderpol

linting
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

benefits -
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 —
development cycle
starts w/ code
then linting
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.

rules types
1. formatting
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

rule sets
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.

reports
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.

autofix
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

ymmv

examples -

css/scss
stylelint - node based, really fast
scss-lint - ruby based, a little sluggish
sass-lint

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

ESLint - JavaScript industry standard linter

.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
phpcs.xml

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)
fix everything?

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
github.com/bookwyrm/screaming-fist

other stuff —

.editorconfig
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

PHP Unit
unit testing for PHP
defacto unit testing for PHP world

Slides: mattvanderpol.com/wc-sacto-2018