If you work inside a team, do yourself a favor – decide on a coding style and get the entire team to use it.
Why Stick To a Standard Code Style?
Making all your teammates’ code look the same will make the codebase so much easier to review, merge and maintain:
- it’ll be easier for you to judge only how the code works, without being distracted by how it looks;
- you won’t have PRs bloated by striping spaces, removing spaces, converting tabs to spaces, moving parentheses on the next line… and so on; less to think about during review; fewer conflicts to fix;
- even if you work solo – I’d argue it’s still very a good idea to do it; adopting PSR-12 in particular will make your code look the same as most well-maintained PHP projects; so when you go look at their code, it’ll actually start looking… a little more familiar; so it’ll be a little easier to learn from them;
- plus, I bet you will adopt PSR-12 one day, so if you start now… you’ll thank yourself later on; be kind to your future self!
Which Code Style to Choose?
Fortunately, thanks to PHP-FIG, it’s easy to choose a standard to start from – PSR-12. Digging a little deeper though, the Laravel ecosystem has pretty much decided on a few rules on top of that. Personally I don’t agree with all of them… but… that’s normal. Ask 10 developers what they like and… you’ll get 10 different answers. So in this case, I found it’s better to just… stick to the Laravel standard. You don’t like X in particular, your coworker doesn’t like Y, and so on, but… you each give in a little bit, for the sake of standardization. Everybody compromises, nobody has a reason to make a fuss… it’s the fair way to go, if you ask me. But hey… you do you 😀
How Do I Automatically Enforce It?
There are quite a few ways to do this automatically:
Option 1. Use StyleCI
If you can use StyleCI, use that. This is why it exists, and it does an excellent job. When someone pushes code to the repo, StyleCI comes in and formats it, by changing their PR to match the code style. It’s simple and brilliant. In fact, we use StyleCI for all the public-source Backpack packages and it’s worked wonders. Just follow the prompts to set it up, then you can forget about it.
If your code is open-source, this is such a good option, that you don’t need to read any further!
However… if your code is closed-source (not public)… you might find your particular company/setup can’t use StyleCI. You might develop A LOT of private projects, that are not under continuous development or maintenance… so you don’t want to pay for a maintenance fee for legacy projects… we get it, we got there too. In that case, the StyleCI pricing won’t make sense for you. In that case…
Option 2. Use PHP-CS-Fixer in Your Editor/IDE
Use php-cs-fixer locally, on each developer’s computer. There are plug-ins for every major editor and IDE, so it should be easy to do. You can store a configuration file in your project root, to make sure you all enforce the same rules.
However, this does assume you can tell your developers “do this, we all need to use the same code style“. In most teams, you can. But even if they do, most developers switch editors, forget to install the plugin, so unstyled code does go through, sometimes. For that reason alone, I don’t trust this method alone. So what I prefer is to…
Option 3. Use PHP-CS-Fixer Inside a Github Action
If none of the above float your boat, there’s one super-simple solution that you can implement, then forget about. It has most of the benefits of StyleCI (it’s implemented where the code is stored, on Github) and most of the benefits of PHP-CS-Fixer (it’s free).
You can implement a Github Action. Every time code is pushed or a pull request submitted, you can run php-cs-fixer on that code and fix whatever is needed. That way, no matter what developers submit, the code will be styled according to the standard.
To be honest, this is the entire reason this article exists – so I get to document how I did this 😀 Hopefully it’ll save you some time (and future me too). Here’s how to go about it:
Step 1. Create a configuration file for PHP-CS-Fixer (.php-cs-fixer.dist.php in your root directory). Here’s the content we use for it, after digging quite a bit. Note that if you don’t have a directory mentioned at the end, you should comment them out, otherwise PHP-CS-Fixer will fail. If you have any comments/improvements on the code style, please suggest them in my gist, it’s open for improvements.
Step 2. Add .php-cs-fixer.cache to your .gitignore file.
Step 3. Add a PHP-CS-Fixer as a dev requirement: composer require --dev friendsofphp/php-cs-fixer
Step 4. Add a Github action/workflow for it, by creating a .github/workflows/format_php.yml file:
name: Apply PHP Code Style
on:
push:
branches:
- 'master'
pull_request:
paths:
- '**.php'
jobs:
php-cs-fixer:
runs-on: ubuntu-latest
steps:
- uses: actions/[email protected]
with:
ref: $
- name: Install
run: composer install
- name: Run php-cs-fixer
run: ./vendor/bin/php-cs-fixer fix
- uses: stefanzweifel/[email protected]
with:
commit_message: Apply php-cs-fixer changes
That should be it. Once you push code to your repo, a new commit should automatically be created, fixing the style. This works particularly well if you work with PRs, because then you squash and merge them and you won’t bloat up your git history.
I hope this will be helpful to you. If you have a better way of doing this, let me know in the comments. I know there are a lot of ways, but this is what I found to be the best for us, in Sep 2021.
Laravel News Links