Tuning Editor Preferences0:00
Okay, so next up, why don't we take just a few minutes to talk about some of the options that are available to you when it comes to things like autoformatting, okay? But first, before we get started, give me 30 seconds, and I'm going to make just a few tweaks that you might consider as well. Okay, first up, notice that I have the User class open, however, that's not represented in the sidebar. And sometimes that's what you want, but often, I like to see that file within the sidebar. Okay, so if I go up here, I'll select the options, and notice right down here, always select open file. Okay, so now, for example, if I go to controller, command P, controller, notice it instantly
select open file. Okay, so now, for example, if I go to controller, command P, controller, notice it instantly switches and opens that controller's directory, and that's what I prefer. But yeah, you may run into situations where that's not what you want, but I find those cases to be somewhat rare. So in situations like that, just turn it off. And once again, you can select it here, but remember, you can use command P. So select open file, and yeah, I can turn it off right from the command prop there. Okay, very cool. The next thing is, if I'm just browsing around the projects tree here, notice that by default,
Okay, very cool. The next thing is, if I'm just browsing around the projects tree here, notice that by default, I have to double click to open a file to the right. Again, I don't want that. So I will select here and choose open files with single click. Okay, so now, I only have to click once to open a file, and yeah, that just feels a little better to me. Okay, so the final change I'm going to make is right here. In recent versions of PHPStorm, they will signal to you whether or not a symbol or a method or a class is being used, and that can be really useful.
In recent versions of PHPStorm, they will signal to you whether or not a symbol or a method or a class is being used, and that can be really useful. But again, personally, I prefer to turn that on when and if I need it. So for now, I will turn that off. And I can simply hover over, right click, and say hide code vision usage in LayHints. And yeah, then right up here, we have the version control as well. Exact same thing. I could hide it, or if you want to configure all in LayHints, you can have a look here. But yeah, it just depends. Turn these on or off as you find them to be useful.
Using Live Templates2:10
But yeah, it just depends. Turn these on or off as you find them to be useful. Okay, very cool. So imagine, and let's go back to the User class. Yeah, imagine we have some non-standard formatting. For example, maybe this brace is up here on the same line. Maybe the imports are out of order and not lined up properly, something like that. Maybe the namespace is way up here. Why don't we add a function down here? A little tip, I can use pubf.
Why don't we add a function down here? A little tip, I can use pubf. This is a built-in snippet or live template. And then I can say test, enter, enter, and we're all set to go. But another option, if I hide this, is I could press Command-J on the Mac, and this will bring up all of the live templates that we have available. So for example, I could look for function again, and yeah, now I can see one version for a standard public method and another one for a static version. So that works as well. Test.
Manual Code Formatting3:05
So that works as well. Test. Okay, anyways, why don't we also put this on its own line? Again, this is just not following typical formatting style guides like PSR-12. So yeah, if I scroll up and I save with Command-S, yeah, by default, PHPStorm doesn't do anything. You have to manually trigger the formatting. And once again, I can use Command-P, and I can look for something like format. Here we go. Format code and format file, and notice the shortcut here. All right, so I will use the shortcut.
Format code and format file, and notice the shortcut here. All right, so I will use the shortcut. And yeah, that works. It has some good defaults out of the box. It doesn't do everything here, but it fixes many of the more glaring issues that you might run into. Okay, now if we want to configure this, I can press Command-,. Let's go into editor, and then right down to code style for PHP files. And yeah, notice we can configure, do we want tabs or spaces? What are the rules for when to add a brace?
Formatting on Save4:30
Okay, so this is great, but it's still not going to work when I save the file. So let's fix that. Once again, Command-comma, and this time we will come down to tools, and actions on save. All right, this is the panel that we want. All right, so let's talk about a few things. All right, so first, do we want to reformat our code whenever the file is saved? We can turn that on and give it a shot. So now I will hit Command-S, and notice it does reformat the file automatically. All right, Command-comma, let's go on back. What about optimize imports?
All right, Command-comma, let's go on back. What about optimize imports? Well, if I turn this on, this will do exactly what you think. It will come way up here, and it will optimize these and order them to the best of its ability. So once again, if I hit Command-S, there we go. And it looks like I'll have to manually fix that namespace, but that makes sense. But yeah, anyways, now the imports are grouped not according to their length, but their namespace. So in this case, all of the Illuminate packages are up here, but this one is Laravel, so that goes down below. Why don't we move it here, save the file again, and notice it reorders them.
goes down below. Why don't we move it here, save the file again, and notice it reorders them. And then finally, this one is an optional trait that you might want to apply to your User class. However, it is commented out, so it's separated. But keep in mind, because we have optimizeImports checked, if we had it like this, because we're now importing it, but I'm not actually using the trait, as soon as I save the file, it will be removed entirely. And again, there might be situations where you don't want that. So you just have to decide whether or not to turn these things on for your own projects.
And again, there might be situations where you don't want that. So you just have to decide whether or not to turn these things on for your own projects. Okay, next up, rearrange code. Again, this is what you would expect. So imagine you have something like this. You have a field that for some reason is below one of your methods. Well, again, that's pretty non-standard. So if I do have rearrange code turned on, yeah, as soon as I save the file, as you see here, it will adjust the order of your constants and your fields and your methods to be a bit more traditional, as you see here.
Code Cleanup Inspections6:24
here, it will adjust the order of your constants and your fields and your methods to be a bit more traditional, as you see here. Okay, cool. All right, next we have run code cleanup. Let's turn that on. Yeah, this is one of the huge wins from using an intelligent IDE. So we can configure the inspections to give you an idea. And yeah, for PHP files, these are all just little tests that the editor will run to confirm, are you doing this in the right way? Could this be replaced with that?
Are there situations where preg_match can be simplified? There's no reason paying that tiny cost if you could instead use something like str_contains. How about this one? preg_split can be replaced with explode. All right, let's have a look and see that in action. So let's imagine we accept a $value here, and maybe the default $value is some $value, and then we're going to split that up into an array of words. Okay, well, you could do something like preg_split, where you have a space as the separator, and then we compare that against the $value itself and save the segments.
Okay, well, you could do something like preg_split, where you have a space as the separator, and then we compare that against the value itself and save the segments. But now notice the squiggly lines here indicating our code check. preg_split can be replaced with explode, which is cool. But also we have a warning icon that will bring up all of the problematic parts of the current file. And yeah, just keep in mind for any of these, if they are not appropriate or relevant for your project, of course, you can disable them so that they don't fire. But yeah, in this case, it looks like we don't have a return type declared. Now, if I wanted to, I could right click and then say show quick fixes.
But yeah, in this case, it looks like we don't have a return type declared. Now, if I wanted to, I could right click and then say show quick fixes. But also notice once again, I could instead on a Mac use Option Return. All right, so let's give that a shot. Option Return. And notice right now my cursor is directly on top of the squiggly lines there. All right, and yeah, here's our quick fix. Add void as the return type. Yeah, notice PHPStorm is smart enough to see, well, at the moment, you don't return anything from the method.
Yeah, notice PHPStorm is smart enough to see, well, at the moment, you don't return anything from the method. So it seems like void is probably what you want. All right, next up, let's do another one. I can select this or again, I can just hover over the issues. In this case, we have an unused local variable segments. So yeah, it's letting you know, hey, this is superfluous. You run this code, but you never do anything with it. So in this case, I bet if I run the quick fix, it removes the line entirely. And it does.
So in this case, I bet if I run the quick fix, it removes the line entirely. And it does. Okay, and then finally, here is our codecleanup, option return, and yeah, it offers to swap that out with a call to explode instead. And actually real quick, while we're here, notice these sort of mocked named parameters. That might be how you refer to it. You might find it very useful or maybe a touch annoying. Again, it's just a preference thing. But again, you can turn that off if you don't want to see them. I can say disable hence for method explode or disable hence entirely.
Integrating Laravel Pint9:20
But again, you can turn that off if you don't want to see them. I can say disable hence for method explode or disable hence entirely. And now they disappear. So yeah, decide for yourself if you want to keep those turned on. I sometimes go back and forth. Okay, so now, yeah, this is all well and good, but I think it would be unfortunate to finish this video without at least a small discussion around Laravel Pint. So let's have a look now. If we visit the Pint documentation on the Laravel website, yeah, we can see it's an opinionated code style fixer for minimalists.
If we visit the Pint documentation on the Laravel website, yeah, we can see it's an opinionated code style fixer for minimalists. So it's effectively a wrapper around a tool called phpcsfixer. That's just kind of easier to use and optimized for Laravel development. So it's possible that if you're switching over to phpStorm, you might already be using a tool like Pint. And of course, if you want to use that in phpStorm as well, you can, I'll show you how. The first step, if you're working along, is to install Pint into your project. So I will do that now. All right.
So I will do that now. All right. And next, you can see that we can run pint by referencing vendor, then pint, and then optionally the path to a directory or a file name. Okay, let's go back to phpStorm. Okay, so this time I will hit command comma and set up a file watcher. And notice at the moment, we don't have any registered. So let's hit configure and let's create a new one. And yeah, this is going to do exactly what you think. It watches a file for changes, and then it triggers any kind of program that you need.
And yeah, this is going to do exactly what you think. It watches a file for changes, and then it triggers any kind of program that you need. So why don't we call this Pint. We are going to watch phpFiles where, yeah, let's use the automatic filtering. There we go. The scope is going to be the project files. That's fine. And then what tool are we going to run? And yeah, if I want, I could select the folder icon here and then browse into my vendor/bin directory and choose our Pint executable.
And yeah, if I want, I could select the folder icon here and then browse into my vendor/bin directory and choose our pint executable. That would be fine. Or if I want this to be dynamic, I can also use phpstorm variables. So I could delete that and add a variable or a macro. It looks like they call them. All right, and I'm not sure what it's called. Let's just look for something like project. Yeah, this is what we want. The directory of the project file.
Yeah, this is what we want. The directory of the project file. And that's what we want. All right, and notice here's the syntax. The variable name or the macro name begins and ends with a $ sign. Okay, arguments. Well, in this case, the argument should be the path to the file. So once again, let's see if we can just find some kind of like relative file path. Let's see. file path.
Let's see. File path. Yeah, nobody expects you to memorize all of these. Yeah, maybe this one. File path relative to the project file. Yeah, so if I save, you know, app/models/User.php, this would give me app/models/User.php. And that's what we want. Okay, next, after the program runs, should we refresh any files in our editor? Yes, the same file.
Okay, next, after the program runs, should we refresh any files in our editor? Yes, the same file. So I will paste that again. And then finally, what is our working directory? Well, again, that's the project files directory. Okay, and then under advanced options, do we want to auto save edited files to trigger the watcher? No, we don't need to do that. I do want to trigger the watcher on external changes. All right, I think that looks pretty good to me.
I do want to trigger the watcher on external changes. All right, I think that looks pretty good to me. So now we've set up a file watcher. If I come back to actions on save, you'll see that it's turned on. Okay, so this is good, but we actually have a problem. Currently, whenever I save a file, we are actually formatting the code two times. Think about it right here. I click save, and then PHPStorm will reformat the project or the code or the file. But then right down here, the file watcher picks up on the change, and then it references the pint program, and that formats the file as well.
But then right down here, the file watcher picks up on the change, and then it references the pint program, and that formats the file as well. Okay, so of course, we don't want to do that. Just pick one or the other. So if we are going to stick with pint, we should disable formatting for PHP files. So I will deselect that, apply it. And yeah, I think we should be good to go here. All right, so let's go into anything. How about back into our controller? And then, yeah, we'll add a function here, test.
How about back into our controller? And then, yeah, we'll add a function here, test. But this time, we will screw up the formatting as you see here. All right, so now if we did everything correctly, when I save the file, it's going to trigger the pint executable, and we should see a little update. I don't know if you saw it, but it was there in the bottom right corner. It calls pint. Pint is triggered on the current file, and then we refresh the file to reflect the change. So once again, I'm going to slow this down, have a look in the bottom right. And there we go.
This is just a simple explanation with no code.
