Posts tagged with code quality
by Freek Van der Herten – 1 minute read – Edit
You can make your code more readable by moving all your exception messages to dedicated classes. We using this technique in all our projects and packages.
– Edit
YouTube star Povilas Korop shares and discusses five rules from our guidelines.
Join 9,500+ smart developers
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.
"As a Laravel developer, this is the one newsletter I most look forward to. Freek has a talent for distilling packages or techniques down to something immediately useful - one tip can save you hours and even weeks. It's concise and practical and highly relevant."
– www.oreilly.com – Edit
Technical debt is not simply a measure of the specific work needed to repay the debt; it is the additional time and effort added to all past, present, and future work that comes from having the debt in the first place.
Read more [www.oreilly.com]
Christop Rumpel shares some good tips on how to refactor code.
Read more [christoph-rumpel.com]
– www.rosstuck.com – Edit
Ross Tuck doesn't blog often, but when he does, it's worth your time!
Read more [www.rosstuck.com]
by Freek Van der Herten – 1 minute read – Edit
Readability of code can be vastly improved by decreasing indentation. In this video we'll reverse conditions and early returns to accomplish this. If you want to see more videos like this one, head over to the video section at Spatie.
– frederickvanbrabant.com - submitted by Frederick Vanbrabant – Edit
My buddy Frederick wrote an interesting post on why he always checks out the admin panel of an app instead of the code.
Read more [frederickvanbrabant.com]
– laravel-news.com – Edit
Tim MacDonald shares a nice way to go about this.
Read more [laravel-news.com]
– evertpot.com – Edit
A nice example by Evert Pot on how you can make static analysers do their work better.
Read more [evertpot.com]
– medium.com – Edit
Kevlin Henney wrote a good post on the importance of naming things well.
Good naming is part of design. It sets expectations and communicates a model, showing how something should be understood and used. If you mean to tell the reader getMillisSince1970, don’t say getTime.
Read more [medium.com]
– twitter.com – Edit
Extracting doesn’t guarantee simplicity. Sometimes extracting code into another module means I’ve smeared one “conceptual module” in my brain into two physical files. Now I can’t look at the whole thing at once, and their internal wiring is more prominent than it deserves. Oops.
— Dan Abramov (@dan_abramov) September 25, 2019
Read more [twitter.com]
– stefanzweifel.io – Edit
Stefan Zweifel shared his GitHub action that can automatically fix code style issues using prettier and php-cs-fixer
One workflow is really like, is to run prettier and php-cs-fixer to automatically format my code and commit the fixed files back to the repository.
Read more [stefanzweifel.io]
– twitter.com – Edit
? In many cases avoiding `else` and using early returns will greatly improve readability of your code.
— Freek Van der Herten (@freekmurze) 17 september 2019
I wish somebody would have told me this sooner in my career.
Contrived example in the image. Real world example: https://t.co/oOsSGAJLZm#bestpractices pic.twitter.com/YgqB0kMIpg
Read more [twitter.com]
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.
Read more [engineering.helpscout.com]
Here a some great tips on how to write robust software.
NASA's JPL, which is responsible for some of the most awesomest science out there, is quite famous for its Power of 10 rules (see original paper). Indeed, if you are going to send a robot on Mars with a 40 minutes ping and no physical access to it then you pretty damn well should make sure that your code doesn't have bugs.
Read more [dev.to]
In an older but still relevant post, Jeff Atwood shares why you shouldn't use boolean parameters and how this translation to UI.
Read more [blog.codinghorror.com]
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.
Read more [matthewrocklin.com]
– www.infoq.com – Edit
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.
Read more [www.infoq.com]
In a new post on his blog Senior CEO Frederick Vanbrabant explains the Integration Operation Segregation Principle, which is programmerspeak for splitting your code into nice little testable bits.
As you can see the Integration Operation Segregation Principle is just a long and complicated term to describe something very simple. This all might seem like a lot of work, but it’s worth it. Your code and especially your tests will thank you later
Read more [frederickvanbrabant.com]
– twitter.com – Edit
? Reviewing your code for symmetry is a great way to improve readability.
— Jason McCreary (@gonedark) September 17, 2018
To get started, check for paired naming, consistent tone, and relative complexity. From there any remaining asymmetric bits will be easy to spot.
Here's a before and after snippet from the @OhDearApp. ? pic.twitter.com/KAhzYBxzSd
Read more [twitter.com]
