This is a more controversial recommendation than PSL1,

which is widely used and adopted.

PSL2 is used widely too, but

has a few parts that some developers are happier about more than others.

The reasoning here, is that PSL2 is a style guide and

each developer has their own unique preferences when it comes to style.

Regardless of the personal preferences of a developer,

using PSL2 has many benefits for your code.

And as everyone conformed to a single code style guide, which helps avoid all sorts

of obscure problems with version control and co-contribution from third parties.

Its also a great set of common rules to follow when you work on a team.

To stop any potential arguments that might pop up about where a bracket should go.

You can just do what PSL 2 does.

I'm gonna take you through the rules in the overview.

One at a time and explain what they mean.

Code must follow PSR1.

To be PSR2 compliant, you also have to follow the rules in PSR1.

PSR2 adds on top of these rules.

Code must use four spaces for indenting not tabs.

This seems counter-intuitive to many.

The tabs versus spaces wars have been going on forever and

will never end, but the important thing is consistency.

The more projects use the same thing, the less IDE config switching you need to do.

PSR2 pick spaces, so that's what we'll do.

Any good editor, can be set to enter up to four spaces when you hit

the Tab key on your keyboard, so this isn't a problem.

There must not be a hard limit on line length.

The soft limit must be 120 characters, and lines should be 80 characters or less.

This just means it would be cool if you kept your code at less than 80 characters,

but that's not always possible.

It probably shouldn't be more than 120 either but if it is,

just give a warning not an error.

There must be one blank line after the name-space declaration.

And there must be one blank line after the block of use declarations.

This just helps things look pretty,

by adding some white space around the namespace declaration.

Opening braces for classes must go on the next line, and

closing braces must go on the next line after the body.

That just means put curly brackets for classes on their own lines.

Opening braces for the methods, must go on the next line, and

closing braces, must go on the next line after the body.

Put curly brackets for methods on their own lines too.

Visibility must be declared on all properties and methods.

Abstract and final, must be declared before the visibility, and

static must be declared after the visibility.

This sounds a little confusing.

But if you're creating an abstract or a final class which is public,

the word abstract or final, should come before public.

If you're using static classes, and

that method is public, then you should write public before you write static.

You might not have learned about abstract final or static classes yet.

These are all fairly advanced features.

So if you're unsure what they are, just ignore this rule for now.

Control structure keywords must have one space after them, and method and

function calls must not.

Control structure keywords are things like if, else, switch, do, while and for each.

You need a space after these words, and before the opening bracket.

Opening braces for control structures, must go on the same line.

And closing braces, must go on the next line after the body.

This means things like if, for each and while, need to have their curly bracket on

the same line as the keyword, instead of dropping it down a line.

Opening parentheses for

control structures, must not have a space after them.

And closing parentheses for control structures, must not have a space before.

That means no white space after the opening bracket, and

no white space before the closing brace.

It can be quite hard to understand what all of this means.

To help us, we can install a tool called PHP_CodeSniffer.

This will allow you to test your code matches against the standard.

Let's hop over to workspaces to see how CodeSniffer works.

If we want to start working with PHP_CodeSniffer,

the first thing we should do is install it.

As with many things, we can use the concert on here and type, composer choir.

The name of the vendor is Squizlabs.

The name of the package, PHP_CodeSniffer.

And once again, this is a dev dependency.

We are only using this for development and not production.

It's gonna ask us to pick a version constraint.

Once again, we don't really care.

So there you can see Composer doing the work.

It's installed CodeSniffer, and now it's there.

Now, just like with PHPUnit, we can run vendor.

Bin, this is where our code lives.

And phpcs, is the executable for CodeSniffer.

Then we pass SRC as an argument,

as that is the only directory we want to sniff right now.

We can leave our tests and vendor folders alone.

Next, we have to specify the standard option.

Two hyphens.

And we want to pass PSR2 as the value to that,

because that's the name of our standard that we want to test against.

If you run this, CodeSniffer should tell us anything that it finds that's

not PSR2 complying in any of the PHP files that exist inside the source folder.

Lets have a look at what it's found.

Okay, here we go, it's found errors inside, source example.php.

Cuz it has, that's the only file that we have.

And there's quite a few errors here.

These numbers here, are line numbers.

This is the severity of the error.

Warnings you can kind of ignore.

Errors are a problem, and

it has a human readable message explaining what's actually going wrong.

Let's have a look at example.php and try and fix it.

So, there must be one blank line after the namespace declaration.

That makes sense.

It also probably shouldn't be jammed up there either,

must be one blank line after the you statement.

Zero found.

Okay.

We can put a line in.

Nice and easy.

Let's try and shrink this list of errors down a little bit.

Okay. What happening now?

Line six, that's here.

Opening brace of a class must be on the line after definition.

Oh, okay. Well the definition line is right here,

and then we have a space and a bracket.

PSR2 says that it should be underlined by itself.

Run again.

Excellent. We're starting to get rid of some of

these errors now.

Class constants must be uppercased.

Expected FOO, but found lowercase foo.

Easy fix.

Don't forget to change any references to this constant as well.

Expected function abc, but

found function abc with a space in between the first parenthesis.

So we don't have a function called abc.

This is just a template error.

What they're really trying to say is,

that on line ten which is right here, there shouldn't be a space here.

So you can get rid of that.

Get rid of a few more of these errors.

Starting to get much more manageable now.

So line ten, still problems with this line.

What's wrong?

Well, we need to put the bracket, opening brace it calls it, down here.

Line 14 is our next error.

The line numbers have changed, so let's update this.

Okay 15, there's a lot of problems on line 15.

We have four different errors with this one piece of code.

So let's take a look.

The static declaration must come after the visibility declaration.

Visibility declaration is public, private or protected.

So it means static, needs to go, there.

Once again, we have the same message, function abc bracket.

Not found, found abc space bracket.

So that's easily fixed.

Okay, getting there.

15, still more problems with 15.

This is a very controversial line.

Expected zero spaces between the opening bracket.

An argument bar, one found.

Expected zero spaces between argument bar and closing bracket, one found.

That means, it expected zero spaces here but found one, delete that space.

It expected, zero spaces there, but found one, so delete that.

And if we look down here it says, opening briefs should be on a new line.

So, that's simple.

Punt that down a line.

Go to the white space.

Let's run this again.

Okay.

White space found at end of line.

There's a few extra spaces there.

Get rid of that.

Inline control structures are not allowed.

Now if you're familiar, control structure is something like if, do, while.

And, inline means that it's all happening on the same line.

PHP allows you to do an inline control statement if there's only one

statement happening.

The problem is, if somebody does something like, then that

doesn't happen inside the IF.

That happens outside of the IF, which is very confusing.

So, to avoid any potential confusion, you just don't use inline control structures

[BLANK_AUDIO]

Okay. There's still problems with line 17.

Expected zero spaces and found one.

Get rid of that, and that.

Keep on running CodeSniffer.

And so we haven't got any errors left.

True, false, and no, must be lower cased.

Expected false but found capital F false.

So, someone used a weird style there.

Let's change that.

And you'll see that now PHP recognizes that as a, as a keyword instead.

On line, 18 we can see that its not been indented correctly,

because there is only two spaces.

They should be four.

Line 21.

Gotta get rid of these spaces.

Also on 21 true, false and null must be lowercased.

Again, someone's used caps lock instead, so we can change that.

Let's run CodeSniffer again.

It all fits on one screen now.

We're getting there.

Expected one space after the function key word.

Which line is this?

30.

Okay, so

when using a function when using an enormous function need to put a space in.

Also on 30, closing breaks must be on a line by itself.

Okay.

One new line at the end of a file.

Oh, we'll get to that in a second.

Each PHP statement must be in a line by itself.

We've still got a problem there.

Very close to having this complete now.

Expected one new line at the end of the file, found zero.

Okay?

There's an empty line.

The closing briefs for the class must go on the next line after the body.

What that means, is that the closing bracket for

the class, this, must be at the end of the body.

That's here.

So, delete that line.

Perfect!

All the errors are gone.

Many IDs and code editors will either have code sniffer built in.

Or available as a plug-in.

Using interactive tools like CodeSniffer, should really help you learn about PSR2.

You don't always need to follow PSR2 in your projects.

But it's slowly becoming far more common for people to do so.