Let's get right into it with formatting. Your code should follow a code style consistently and automatically. If you're in the code and you're adding things like line breaks and you're lining up, uh, assignment operations, you're not really being a programmer, you're being a typist. I know that might be hard to hear. Early in my programming days, I took all this stuff personal. I got into all the arguments, tabs versus spaces,

I took all this stuff personal. I got into all the arguments, tabs versus spaces, curly bras, indentation. It took me a long time to realize that's not the mark I wanna leave on the code. I don't wanna be remembered as the programmer who got into arguments about indentation. I wanted to be remembered for writing better code. Going back to the code sample we saw in the previous video, we know that formatting matters.

Going back to the code sample we saw in the previous video, we know that formatting matters. Simply applying a code style can make the code more readable. Again, the white space and its placement may be subjective, but there's no denying that applying a code style matters, at least on a fundamental level. This is because as humans, we learn how to read. We don't know how to read. When we're born, we're taught how to read even more.

We don't know how to read. When we're born, we're taught how to read even more. So as programmers, as we're taught the syntax and a structure of a language, we can demonstrate this simply by reading a sentence. It has a structure. The words are together. There's spaces between them. There's some syntax, such as a period at the end of the sentence, if we start messing with that structure, if we start messing with the syntax,

of the sentence, if we start messing with that structure, if we start messing with the syntax, things undoubtedly become much harder to read. Kevlin Heney has a similar demonstration with what he calls the visual representation of code to avoid us from looking at the syntax as programmers, he replaces all of the characters with the letter X. He leaves the white space in indentation alone. The result allows us to see the structure of the code, maybe at an unconscious level.

The result allows us to see the structure of the code, maybe at an unconscious level that our brains would when we're reading it. So take the visual representation of this code. Right now it's unformatted, but if we add some simple indentation, some line breaks, it starts to take a structure, one that even without seeing the syntax, we might be able to guess. In this case, we see indentation levels such as a sub block

we might be able to guess. In this case, we see indentation levels such as a sub block of code, and maybe we would guess this is a method declaration. Knowing how this works, let's take a look at one more example. Again, un reformatted, but as we start to introduce line breaks and indentation, the structure of the code starts to take shape.

and indentation, the structure of the code starts to take shape. If we count some of the characters, we might even be able to guess this is an if else block. So having the code formatted allows us to rely on common structures and convention. This allows us to scan the code or our brain to take shortcuts just as it does when reading spoken language. Now, I'm not gonna dictate which code style you should use.

as it does when reading spoken language. Now, I'm not gonna dictate which code style you should use. Again, you may have strong opinions. You should decide for yourself or with your team. What matters is that you can apply your code style consistently and automatically. All programming languages include a code formatter. Some are offered as a third party tool, some are built right into the language.

Some are offered as a third party tool, some are built right into the language. Since this is laravel cast, I'm gonna focus on Laravel or php, and there are three main code formatters for php. The oldest is PHP_CodeSniffer, probably more widely used is PHP CS Fixer, and again, probably being a Laravel developer, you may be most familiar with Laravel Pint. Now, I prefer Laravel Pint, not just because I'm a Laravel developer, but

Now, I prefer Laravel Pint, not just because I'm a Laravel developer, but because it's actually built on top of PHP CS Fixer. So by using Pint, I'm actually getting two of the top three code formatters per PHP. What I also like about Pint is that it has A-J-S-O-N configuration file. Instead of using a PHP script for configuration like PHP CS Fixer does, while it's included in every new Laravel project,

for configuration like php-cs-fixer does, while it's included in every new Laravel project, I'm gonna require it. In ours, I'll demonstrate pint by applying some common code styles preset into the tool. So we can run vendor/bin/pint directly on our formatted file, and we'll see that it applies Laravel code style by default. In jumping back to the code, we can see that it's styled.

and we'll see that it applies Laravel code style by default. In jumping back to the code, we can see that it's styled. Let's go back to the original UNFORMATTED code and let's use one of the other presets. Let's say for example, you wanted to follow the PSR 12 code style, so we could say preset equals PSR 12, and we'll use again, just strictly our formatting file. So we'll see that it also applied very similar rules to it, but its structure is just a little bit different.

So we'll see that it also applied very similar rules to it, but its structure is just a little bit different. For example, I know that there's a line break between this return for the Laravel code style. Again, going back to the UNFORMATTED code, I know that a lot of IDEs these days can auto format your code for you. For example, I can do command option L in phpstorm and it'll format it pretty close to that PSR 12 preset. If not exactly,

and it'll format it pretty close to that PSR-12 preset. If not exactly, but being able to apply this in your editor isn't necessarily reusable. Maybe not everybody uses PhpStorm. So I would advocate using one of these tools and one of the presets. Again, I know that might be difficult at first, up until just a few years ago, I still had my own custom code style.

until just a few years ago, I still had my own custom code style. It mostly followed Laravel, but I couldn't get used to that concatenation operator being right up against the strings with no space around it. It felt like Java to me. I reached a point where I realized it was silly to even copy around that json configuration file between my projects as a Laravel developer for almost 10 years now,

around that pint JSON configuration file between my projects as a Laravel developer for almost 10 years now, having my code look exactly the same in every project, as well as exactly the same as the code within the Laravel framework allowed me to context switch more easily to read the code without any friction, and that to me is in valuable.