In this old, but still relevant, blog post Craig Davis explains what guard clauses are and how they can be used to clean up your code.
We’ll first explore several versions of a sample method from a hypothetical billing system. For these purposes, we’ll assume this is code in an existing system and we’ll look at refactoring it to reduce complexity and make it easier for a programmer to understand. The first example will be trivial enough to easily understand, but we’ll build on it in the final examples.
Matthew Rocklin reminds us that sometimes you shouldn't extract code.
However, there is also a cost to this behavior. When a new reader encounters this code, they need to jump between many function definitions in many files. This non-linear reading process requires more mental focus than reading linear code.
Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime.
You can also follow me on X.
"Freek publishes a super resourceful and practical newsletter. A must for anyone in the Laravel space"
A nice little tip to clean up your code base from boolean flags (is_active, is_deleted, is_subscribed) is to switch to nullable timestamps instead. You remain the same flag functionality, but get the point of time for free. pic.twitter.com/86iHt6ow0X
In our recent projects at Spatie, we've started using a concept called "actions". It keeps our controllers and models skinny. It's a straightforward practice. In this blog post, I'd like to explain it to you.
Refactoring is an excellent book written by Martin Fowler. He recently released a second edition. I'm reading it now and can recommend it to anyone interested in writing better code. Here's an interview with the author on the second edition of the book.
InfoQ interviewed Fowler about the major changes in the 2nd edition of Refactoring, how to recognize code smells and refactor code, how code reviews and refactoring support each other, what tech leads can do to encourage refactoring, the benefits refactoring brings, using tools for refactoring, and mob programming.
While working on a package I found myself trying to combine some data. This is what my code looked like. Assume that $locales and $fields are arrays that are already populated. collect($locales)->each(function (string $locale) { collect($fields)->each(function (Field $field) use ($locale)…
In an older but still relevant article on the Clean Coder Blog, Uncle Bob argues that the structure of your tests should not necessarly reflect the structure of your code.
The structure of the tests must not reflect the structure of the production code, because that much coupling makes the system fragile and obstructs refactoring. Rather, the structure of the tests must be independently designed so as to minimize the coupling to the production code.
Whenever you find yourself using || or && in an if statement, consider extracting the conditions of that if statement to a dedicated method with early returns. It's more readable and it makes debugging much easier.
A couple of weeks ago GitHub removed the last usages of jQuery in their front end code. On their engineering blog that share why and how they removed it.
We have recently completed a milestone where we were able to drop jQuery as a dependency of the frontend code for GitHub.com. This marks the end of a gradual, years-long transition of increasingly decoupling from jQuery until we were able to completely remove the library. In this post, we will explain a bit of history of how we started depending on jQuery in the first place, how we realized when it was no longer needed, and point out that—instead of replacing it with another library or framework—we were able to achieve everything that we needed using standard browser APIs.
Here's another awesome blogpost by my collegue Seb. In this one he explains why you should and how you can create an explicit Vue component API.
When refactoring your UI to components, always keep in mind that props and events are your components public API. Just like when you're modelling your application's domain, try to keep things explicit. Props and events should be enough to tell the outside world everything it needs to know about a component's behavior.
Mattias Noback shares how you can migrate a code base that fetches its dependencies using static method calls to code that uses dependency injection.
I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.
? Super simple clean-up, but the cause of so much "dead code". When using `return` statements within a `switch` block the `break` is unnecessary and is always unnecessary for the `default` case. pic.twitter.com/QxjFmiGcYy
Rémi Collin shares a cool approach on where to place code that doesn't really belong in a controller. He creates small, reusable, testable, decoratable classes, called Actions.
Using this approach can seems a lot of classes at first. And, of course the user registration is a simple example aimed to keep the reading short and clear. Real value starts to become clear once the complexity starts growing, because you know your code is in one place, and the boundaries are clearly defined.
Matt Stauffer shares some interesting refactors suggested by his co-workers on a Vue component he wrote.
I've written some Vue since 2015, but I've also learned some React, written a lot of Laravel, run a company, and spent much of my free time writing a book about Laravel. It's time for me to get back into Vue.js and really spend some time to get good at it. Thankfully, some of the best Vue developers out there work at Tighten, so I'm putting them to work to level me up. So, I'm going to be writing new Vue code and also cleaning up some of my Vue from 2015, and I wanted to share the process with you, my lovely readers.
In a new video Jason McCreary, the creator of the wonderful Laravel Shift, demonstrates a few good tips to clean up code. In the video below Jason uses a code snippet taken from my side project Oh Dear!
Mattias Noback gives some good tips for refactoring legacy code.
"Combing" legacy code by untangling the strings is a good way to improve it and take back control over it. In existing legacy code, you should stop (re)using existing methods, making them ever more generic. Instead, you create new methods, and copy code from existing ones, allowing you to simplify this copied code and end up with a manageable class.
Here's a video of a great talk by Sandi Metz she gave at RailConf 2015.
Our code is full of hidden assumptions, things that seem like nothing, secrets that we did not name and thus cannot see. These secrets represent missing concepts and this talk shows you how to expose those concepts with code that is easy to understand, change and extend. Being explicit about hidden ideas makes your code simpler, your apps clearer and your life better. Even very small ideas matter. Everything, even nothing, is something.