Freek.dev

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.

https://guidelines.spatie.be

Read more

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.

Read more

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

Read more

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.

Read more

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.

Read more

In my day to day work I don't write any css at all, but I still very much enjoyed this blogpost by Adam Wathan where he shares some interesting things about how css should be structured and he makes the case for using utility classes to make visual tweaks.

When you think about the relationship between HTML and CSS in terms of "separation of concerns", it's very black and white.

You either have separation of concerns (good!), or you don't (bad!). This is not the right way to think about HTML and CSS. Instead, think about dependency direction.

...

One of the biggest benefits of using small, composable utilities is that every developer on your team is always choosing values from a fixed set of options.

https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

Read more

Ross Tuck is probably one of my favourite bloggers. He doesn't publish something often (his previous post is from 2015), but when he does it's very much worth your time.

The important takeaway here isn’t “value objects, yay, inline juggling, boo!” It’s that we were able to remove several classes of errors by reducing the precision of the DateTime we were handling. If we hadn’t done that, the value object would still be handling all of these edges cases and probably failing at some of them too.

Reducing the quality of data to get a correct answer might seem counter-intuitive but it’s actually a more realistic view of the system we’re trying to model. Our computers might run in picoseconds but our business (probably) doesn’t. Plus, the computer is probably lying anyways.

http://rosstuck.com/precision-through-imprecision-improving-time-objects

Read more

Grégoire Paris wrote down his opinion on why he dislikes Yoda conditions.

So how do Yoda conditions work? Well it is basically a knee-jerk reaction you have to develop: whenever you write a condition, put the operand that cannot be assigned on the left. This should give you an error message if you make an assignment when you actually meant to make a comparison.

https://dev.to/greg0ire/why-using-yoda-conditions-you-should-probably-not

Personally, I'm not a big fan of Yoda conditions either. My feeling is the the cost of decreased readability is just too high for the small value that Yoda conditions bring to the table.

Read more

?Combining query scopes with explicit model names will help keep code cleaner and easier to understand #laravel pic.twitter.com/ixzDdrZcRT

— Chris Gmyr (@cmgmyr) July 12, 2017

Read more

David Négrier, CTO of the CodingMachine, wrote a nice article on why he likes and how his team uses typehints.

As a developer consuming this function, I know how to use it. And if I’m using it wrong, I’ll know right away because PHP will crash with a nice error message when the function is called rather than with a cryptic error some time later.

https://www.thecodingmachine.com/type-hint-all-the-things/

Personally I like typehints too, because the potential readability improvement the article touches upon.

Note: (I only include this paragraph because it's mentioned in the intro of the article, don't want to stir up a discussion) the fuzz about that "Visual Debt" video was overblown. Even though I didn't agree with all of it, it was nice to hear Jeffrey's way of thinking.

Read more

Brent Roose wrote down his thoughts around how things like fonts, spacing, docblock, ... can influence the cognitive load of a programmer.

As a professional programmer, I'm reading and writing code on a daily basis. I'm working on new projects, doing code reviews, working with legacy code, learning documentation etc. Based on my own experience and that of colleagues, being a programmer often involves a lot more reading than actually writing code. Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

https://www.stitcher.io/blog/a-programmers-cognitive-load

Visual debt is real.

Read more

? Go crazy with Blade directives. The simplest things can abstract away tons of visual noise from your templates. pic.twitter.com/p5udGWJkhd

— David Hemphill (@davidhemphill) June 22, 2017

Read more [twitter.com]

Mattieu Napoli shows how you can use non breaking spaces to make long test function names more readable.

Yes. This article is about using non-breakable spaces to name tests. And the fact that it’s awesome. And why you should use them too.

public function test a user can add a product to a wishlist() { // ... }

The code above is valid PHP code and works. Non-breaking spaces (aka   in HTML) look like spaces in editors but are actually interpreted like any other character by PHP.

http://mnapoli.fr/using-non-breakable-spaces-in-test-method-names/

It's cool that it works, but I'm not really a fan of this. I very much prefer how test runners like jest go about this by passing the name of the test to a function so you can use spaces.

Read more

In a new post on his blog, my favorite stalwart of the industry Frederick Vanbrabant, gives a explanation on why some projects turn into a big mess and how you can avoid it.

I truly believe that the broken window theory can be applied to software projects. In my personal experiences I’ve rarely seen a project start out as a total mess. If it ended up as a mess, it was gradually. I also believe that this is not necessary the fault of developers working on the project, think of it more as frogs in a pot with gradually increased temperature of water. One morning you just wake up and take a look at the project and realise that it has gotten really messy.

http://frederickvanbrabant.com/2017/06/12/broken-windows-theory.html

Read more

In a new blogpost on vemv.net the author (I couldn't find his real name) argues against using a simple status field.

Dear programmer, do you ever use the name state for your variables? Like state = 42? “Hell no, that’s a terribly generic word. Better to use the domain-specific wording the variable refers to: is_invoiced, visit_count, shopping_cart, things like that.”

Sounds reasonable. But sometimes, you have a database column called status, and use it through your codebase, right? “Yes.”

Were you aware that status and state mean basically the same thing in English? “Uhm…”

https://blog.vemv.net/the-status-antipattern-479c26c7ddf7

Read more

In this article Kent C. Dodds clearly explains what the downsides are of using Class in JavaScript.

Classes (and prototypes) have their place in JavaScript. But they’re an optimization. They don’t make your code simpler, they make it more complex. It’s better to narrow your focus on things that are not only simple to learn but simple to understand: functions and objects.

https://medium.com/@kentcdodds/classes-complexity-and-functional-programming-a8dd86903747

Read more

On the Tighten co blog Caleb Porzio wrote a small post on how you can boot your model traits. It's a very handy feature that's being used a quite a few Spatie packages.

TL;DR Use bootNameOfTrait() instead of boot() in a model trait to avoid being overwritten by the base model’s boot() method.

https://blog.tighten.co/laravel-tip-bootable-model-traits

Read more