Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed PHP Standards and Best Practices!
You have completed PHP Standards and Best Practices!
Preview
This recommendation was designed to avoid code from one package negatively effecting the global state of the application, or conflicting with another package, and is important to any OOP code put on Composer.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Now you know how to structure your PHP
code and you know how to auto load it.
0:01
It's the huge amount of the work.
0:04
You can create all source of code using
various different design patterns but
0:06
loading one class is the same as loading
multiple.
0:09
You just have to use an auto loader and
name spaces to structure your code.
0:11
Over the last few years, it's become more
and
0:15
more common for people to use established
standards and recommendations to
0:17
increase interoperability and consistency
between various projects.
0:20
As this course is all about best
practices,
0:24
it seems only reasonable to use these for
components.
0:26
PSR-1 is a standard recommendation which
provides you
0:28
with a list of good ideas to implement.
0:32
If you only implement a few of them,
0:35
then you are not technically compliant
with PSR-1.
0:36
But the more of these rules you follow,
the better.
0:38
In fact, there's barely any reason to
ignore a rule in PSR-1.
0:41
Here are some of the rules.
0:44
PHP code must use the long tags, or the
short echo tags.
0:46
It must not use other tag variations.
0:49
Historically speaking, there are a few
different tags you can use in PHP.
0:52
There are long tags, short tags, short
echo tags, and some other ones like,
0:54
asp star tags.
0:58
PSR-1 suggest that you only use long tags
and short echo tags.
1:00
We discussed character encoding in UTF8 in
an earlier lesson,
1:05
and PHP should have its own files written
in UTF8.
1:08
This allows unicode characters to be used
in actual PHP code and
1:12
not just when worrying about output.
1:15
Many editors like sublime and PHP storm,
will use the setting by default, but
1:17
it's worth checking your settings or
preferences.
1:21
If we go to the php-fig.org website and
1:25
scroll down a little bit, we can see
PSR-1.
1:27
This will take us to a page containing all
of the rules,
1:30
some of which I've already discussed.
1:33
One rule I'd really like to highlight can
be found about halfway down the page
1:35
under 2.3 side effects.
1:39
The rule starts here.
1:42
A file should declare new symbols,
classes, functions,
1:43
constants, et cetera, and cause no other
side effects.
1:47
Or, it should execute logic with side
effects but should not do both.
1:50
And this sounds like a bit of a
complicated statement.
1:54
But it's a really, really good rule.
1:57
It basically means that when you build
your components, packages, classes or
1:59
whatever, you should do one of two things.
2:02
Either define functions, classes,
constants, et cetera.
2:05
Or, do things like setup, changing config
values including on the files output and
2:08
content like HTML or JSON.
2:13
You can only do one type of action on the
same file, never both.
2:15
Let's have a look at some examples of
this.
2:18
On the PSL1 document itself.
2:21
You can see a few examples here.
2:24
So, the first example, here we're changing
the error reporting value to E_ALL.
2:26
Now, that might be fine if you're in a
bootstrap file.
2:31
But if this is in some other class, it
could be terrible.
2:33
Imagine you include a file to use a
function or a class that's declared there.
2:36
But at some point in that class, maybe
before, or
2:40
maybe inside of a function or a method,
the author decided to turn off notices.
2:42
Some developers do this when their code is
written quite poorly, and it has a lot
2:47
of notices, it's generally quicker to turn
them off than actually fix them.
2:50
If you expect notices to be turned on and
then they're suddenly turned off
2:55
without you noticing, you can end up
having a really bad time.
2:58
The same can be said for any label
setting.
3:01
Don't change default time zone or the
display arrow settings or memory limit or
3:03
anything inside the same file as a class
or
3:08
function you are expecting people to use.
3:10
Including another file from another file
can lead to some complex issues.
3:12
If I include file A then file A includes
file B but
3:17
I've already included file B myself,
3:20
then we'll get a fatal error because it's
trying to re-declare the same class.
3:23
If I avoid that by not including file B
myself, and
3:26
somebody changes file A to not include
file B,
3:29
then we get another fatal error because
that class hasn't been included.
3:31
Generally, try and keep file loading to a
minimum.
3:35
Especially in files where you're defining
functions and classes.
3:38
This next example highlights a side effect
which is generating output.
3:41
So outputting any output in a file when
you only expect to
3:45
include a class is a recipe for disaster.
3:49
Accidentally outputting HTML can break
redirects that might happen earlier in
3:51
the page, or cause broken sessions, or all
sorts of other really weird things.
3:54
So finally the last rule here is an
example of a declaration.
3:59
As PSR-1 suggests, you should either
declare or run side effects,
4:01
but never both.
4:06
So a declaration, as mentioned, could be a
function or a class.
4:07
It could also be a variable or a constant
or basically anything you're defining.
4:11
Another rule of PSR-1 is the namespaces
and classes must follow PSR-0 or PSR-4.
4:16
That should be fairly easy as we know how
PSR-4 works already.
4:22
They're both auto-reading standards and do
essentially the same thing.
4:24
Neither of them care too much what you
actually name your Namespaces, Classes and
4:28
Methods, PSR-1 does.
4:32
Namespaces and Classes need to use studly
caps, which means use a capital letter for
4:34
each new word and everything else is a
lowercase letter.
4:39
Methods need to use camel case, which is
just like study caps, but
4:42
the first character in the whole method
should be lowercase as well.
4:46
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up