PSR-14:49 with Phil Sturgeon
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.
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 up