Posts tagged with best practices
Frederick Vanbrabant published another delirious rant on his blog. This time it's about atomic commits.
Atomic commits, sometimes also called micro commits, is the practice of explaining your thought process in the form of commit messages and code. It comes down to documenting the way to the solution.
https://frederickvanbrabant.com/2017/12/07/atomic-commits.html
???? Symmetry is a hallmark of clean code. Symmetrical code is not only easy to read, but also predictable. Here are a few areas to check your code for symmetry. pic.twitter.com/jGVdR0aek7
— Jason McCreary (@gonedark) November 30, 2017
Read more [twitter.com]
Join 9,000+ developers
Every month, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.
No spam. Unsubscribe anytime. You can also follow me on X.
Probably you know that that keeping the disk & transfer size of a JavaScript file low is pretty important. But have you considered the time needed to parse and compile the code? In this great post on Medium Addy Osmani, an engineer at Google, explains the complete cost of having JavaScript on your page.
As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this post, I’ll cover why a little discipline can help if you’d like your site to load & be interactive quickly on mobile devices. tl;dr: less code = less parse/compile + less transfer + less to decompress
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
My colleague Brent published a new blogpost on how the ternary and null coalescing operators work in PHP.
You've probably used the ternary ?: and the null coalescing ?? operators in PHP. But do you really know how they work? Understanding these operators makes you use them more, resulting in a cleaner codebase.
???? Pushing yourself to remove comments is one of the best drivers towards clean code. Here's a few tips on how to spot and replace comments that may be unnecessary… pic.twitter.com/STIK6AIKXt
— Jason McCreary (@gonedark) 16 november 2017
Read more [twitter.com]
? Symmetry in naming is a powerful tool I never gave the weight it deserves. Embrace the visual relation! A common example in Vue: pic.twitter.com/QEBbHDUvWY
— Caleb Porzio (@calebporzio) November 9, 2017
Read more [twitter.com]
Harry Roberts makes the case for making technical debt visible instead of trying to hide it.
This means that, although far from ideal, the impact of these hacks is well contained and signposted, meaning that they won’t slip through the cracks and remain hidden in the codebase for the next five years.This pragmatism and lack of stubbornness can make your codebase much more malleable, resilient, and ultimately much more useful. Everything is a compromise.
Jason McCreary, creator of Laravel Shift, wrote a down a two part series on how to write cleaner code.
To measure our change, we should ask: Did we improve readability?Admittedly a bit subjective, but you push yourself to stay objective. I've been pair programming for the last two years. Developers tend to agree on fundamental readability. Where we differ at the edges. These nuances can lead to some pretty great discussion.
...
The answer to did we improve code readability may vary from developer to developer and project to project. But always ask the question…
https://dev.to/gonedark/writing-clean-code https://dev.to/gonedark/writing-clean-code-part-2-9fn
You can spend a lot of time to make emails look pretty, but it might be better to just don't style them at all. Greg Kogan did some A/B testing an concluded that sending plain emails results in more opens, clicks, replies, ...
Why are the plain emails crushing the performance of designed emails?
- They're less likely to be caught in spam filters. Having less HTML and fewer non-text elements such as images lowers the likelihood of triggering spam filters. You can use a free spam checker to validate this by testing plain and designed emails.
- They're less likely to go into the "Promotions" tab in Gmail (used by ~16% of all email users), for the same reasons above. From my testing, the plain emails typically end up in the Updates tab and some times even in the primary tab. Of course, the text in the email also affects this.
- They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.
- They feel more personal. It's no handwritten note, but it's much more personal than an over-designed email with the recipient's first name crammed somewhere inside.
Caleb Porzio gives some good advice on how to make code more readable in this talk given at Erie Day of Code 2017.
A few ways to clean up the conditional code that forms most of your codebase. From simple to nested to spotting unnecessary conditions. ? pic.twitter.com/qGVaDl3TKt
— Jason McCreary (@gonedark) October 26, 2017
In his excellent talk given at Laracon Online 2017, Adam Wathan argues that testing in isolation leads to brittle test and that integration tests are much more valuable.
In a fantastic post on his blog, Kent C. Dodds makes the case for focusing on writing integration tests, and stop going for 100% code coverage. Amen to that!
You may also find yourself testing implementation details just so you can make sure you get that one line of code that’s hard to reproduce in a test environment. You really want to avoid testing implementation details because it doesn’t give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code.
https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c
The maintainers of Vue.js have recently published their official style guide.
This is the official style guide for Vue-specific code. If you use Vue in a project, it’s a great reference to avoid errors, bikeshedding, and anti-patterns. However, we don’t believe that any style guide is ideal for all teams or projects, so mindful deviations are encouraged based on past experience, the surrounding tech stack, and personal values.For the most part, we also avoid suggestions about JavaScript or HTML in general. We don’t mind whether you use semicolons or trailing commas. We don’t mind whether your HTML uses single-quotes or double-quotes for attribute values. Some exceptions will exist however, where we’ve found that a particular pattern is helpful in the context of Vue.
https://vuejs.org/v2/style-guide/
Want to see some more style guides? At Spatie we have a guidelines site containing styleguides for Laravel and JavaScript.
This site contains a set of guidelines we use to bring our projects to a good end. We decided to document our workflow because consistency is one of the most valuable traits of maintainable software.The contents of this site exist for ourselves—more importantly, our future selves—and for giving future collegues a reference to our way of doing things and their quirks. The guidelines cover workflow, code style, and other little things we consider worth documenting.
At last years Istanbul Tech Talks conference Kevelin Henney gave this great talk on how to improve the readability of your code.
Here are the slides of this talk.
Jens Segers, developer at Teamleader and author of the popular Optimus and laravel-mongodb packages, wrote about an alternative to controllers.
Let me introduce you to request handlers. The concept is very simple, yet very unknown to a lot of PHP developers. A request handler is basically a controller, but limited to one single action. This concept is very similar to the Action-Domain-Responder pattern which was proposed by Paul M. Jones, an alternative for the MVC pattern that focuses on a more clear request to response flow for web applications.
https://jenssegers.com/85/goodbye-controllers-hello-request-handlers
This works in Laravel 5.5 because $request->validate() only returns the validated data. Beautiful.
Yeah. I had originally sent that PR. I love it. Makes for these lovely controller methods. Just look at this❗ pic.twitter.com/FlxIlJVQXN
— Joseph Silber (@joseph_silber) September 14, 2017
Read more [twitter.com]
Colin DeCarlo, a developer at Vehikl, wrote some thoughts on why PHP has a bad reputation in some circles.
People shitting on PHP isn’t going to go away, it’s a symptom of a few things. PHP has a ridiculously flat learning curve so just about anyone can write code using it, this means a lot of amateurs and ‘get it done’ developers will choose php but won’t really ever level up their skills when it comes to software development.
https://medium.com/@colindecarlo/who-uses-php-anyway-672115ab81de
I agree with Colin on everything he writes in his post. I'm also thinking that the some of the reasons on why people don't like PHP apply to Laravel as well. In my mind Laravel is to PHP frameworks what PHP is to other programming languages. Both Laravel and PHP might not do everything by the "real programming rules", but it sure is easy to use. And when handled properly powerful and maintainable stuff can be built with it.
Because Laravel is an easy framework to get started with, it's a popular choice for newcomers. Even with almost no experience you can build an app. Some of those projects will go to production. If an experienced developer that uses another framework comes by and sees that Laravel app, it might be easy to conclude that the problem lies with Laravel, and not with the inexperience of the junior programmer who just begon his/her journey in coding.
Jeff Madsen wrote down a good piece that explains how mutable Carbon dates can lead to some nasty bugs. I would't mind if Chronos were to be promoted to the default datetime library in Laravel.
If you hang out on any sort of programming forums you have no doubt encountered “The Great Mutable vs. Immutable Debate”. While I’m sure you know what the words mean, if you are new to programming or don’t have a strong Computer Science background it might not be obvious to you whether this is an important concept to be concerned with, or just more “architecture astronaut” purists arguing some obscure fine point.To help you answer that for yourselves, I’m going to show you the difference between the two using two popular Php DateTime libraries — Carbon and Chronos, and then demonstrate the danger of using the mutable one of those.
https://medium.com/@codebyjeff/whats-all-this-immutable-date-stuff-anyway-72d4130af8ce
If you want to read more cool articles by Jeff, be sure to subscribe to his excellent newsletter.
At Spatie we recently launched a new site: guidelines.spatie.be. It contains articles on how we go about setting things up at Spatie and a collection of styleguides. The source code of the site is available on GitHub. In this blogpost I'd like to share why and how we created our guidelines site. Why…