Freek.dev

Laravel / PHP / AI

Posts tagged with code style

Tools to automatically format PHP, JavaScript and CSS files original

by Freek Van der Herten – 2 minute read

When working on a project with other people, it's important to pick a coding standard. A coding standard like PSR-2 in the PHP world specifies rules on where certain characters, like braces of an if statement, or comma's should be put. Agreeing on a coding standard makes the code more readable for…

Read more

Join 9,500+ smart developers

Every month I share 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.

Where a curly bracket belongs

My colleague Brent has some good thoughts on where to place curly brackets.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

https://www.stitcher.io/blog/where-a-curly-bracket-belongs

Read more

The official Vue.js style guide

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

Formatting Vue component properties in PHPStorm

Most of work is done in PHPStorm. On my current project I do a lot of Vue stuff. Regularly use PHPStorm auto format feature to make the code look nice. One thing that was bothering is that by default it will use 8 characters of indentation for Vue component properties. So you get this horrible code:

<br /><template>
    <!-- ? -->
    <my-component
            myProp="myValue"
            anotherProp="anotherValue"
    ></my-component>
</template>

Today a golden tip by Christopher Pitt helped me find the solution. In the preferences of PHPStorm you need to set continuation indent of the html to 4 characters.

And after that the PHPStorm will reformat the code right according to our guidelines for Vue templates.

<template>
    <!-- ? -->
    <my-component
        myProp="myValue"
        anotherProp="anotherValue"
    ></my-component>
</template>

Read more

Why using Yoda conditions you should probably not be

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

Dropping the public keyword

Evert Pot makes some sound arguments in favor of dropping the public keyword.

I think people should be using "var" instead of "public". I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discusssions), but hear me out!

Over the last year I’ve been going through all my open source projects, and I’ve been removing all the public declarations where this was possible.

...

"public" is completely optional. "public" is the default, so adding it does nothing to your code.

https://evertpot.com/drop-public-not-var/

Read more

Converting big PHP codebases to PSR-2

It is known by now that every codebase large enough (in terms of lines of code or people collaborating to it) should follow any code standard. Here at Coolblue we weren’t different and were using our own coding standard.

But codebases evolve. And our codebase – that has been supporting one of the most visited ecommerces in The Netherlands – needed to be upgraded to a coding standard that’s a little bit more up to date.

This is the process we follow to move into PSR-2.

http://devblog.coolblue.nl/tech/converting-big-php-codebases-to-psr2/

In the past months we converted several of our old projects to PSR-2 with Fabien Potencier's coding standards fixer and had zero issues doing so. Hurray for standardized code.

 

Read more