 Hello. I'm Phil, and I'm going to talk to you today about code review and how you can become a better developer, hopefully, by doing code review. As a developer, you might think that code review isn't something you really want to do. You want to write code, not read code, but I promise you it can help. So, just a little bit about me. I work with WordPress.com VIP, and we do cloud hosting and support for high-profile, high-traffic WordPress sites. We look after some of the world's biggest runs who are using WordPress every day. We keep their sites secure, scalable, and safe. And we do that through code review. One of the reasons why these runs use this is because we do code review. It's one of the top things that they say is a benefit of the service we offer them. So, hopefully, quite a few of you have seen this. This is the first line of the automatic CREED, automatic being my employer, obviously. And as a developer, you have to learn constantly, all the time, because web development never stays still. And you can do that by doing code review. So, what is code review? You're basically looking at standards, the standards that are around to help you make sure your code is of good quality. You're looking for simple mistakes. Everyone's done the odd missing semicolon thing. Send it to checking, making sure the code does what it's supposed to do, making sure the logic follows through. And also looking for any performance issues. Maybe you've accidentally put in a nasty query that's going to load on every single page of your website, and it's going to take your database down if you get a spike of traffic. So, why do it? So, you want to keep your site safe? You want to make sure it's secure? You want to make sure that it's not easy to hack? You don't want to leak any papers about tax avoidance, for example? You want to make sure that it's scalable? That if you do get a nice big spike of traffic, or you've got a high traffic website, that it's going to handle that traffic? That you're going to be able to take several million page views, for example? You want to make the code readable as well? We've all done this, we've all gone back to our own code even, later down the line, and looked at it and thought, what the hell was I thinking? This is terrible code. Or you can't understand what it's doing. You've got a bunch of code and it doesn't say anything about what it's actually doing. So you need to make sure it's understandable. Finally, but not obviously not least, is to learn. You can learn a lot by doing code review. You learn from your own mistakes when you've gone back to your code many years later. You see what you've done wrong and you can fix that in the future. You can learn from other developers' code, you can see what they do differently, pick up on different ways to do things just from reading their code. And this is what helps you to become a better developer. You look at code and you see other things, you see mistakes you've made and you can learn those. You can use standards and internalise those and make sure that when you're writing code in the future, that actually you're remembering those lines that you've read before. And you can take that in and think, hang on, previously I might have written this conditional this way, but actually I'm going to write it in this way because I've seen that before and it seemed like a better way to do it. Or I know it's a better way to do it because the standard said so. So there's lots of ways you can do code review. You can do automated code review to start with. One of the ways you can do is use PHP code sniffer. And there's some WordPress coding standards that you can use with PHP code sniffer to automatically look at your code and say, well, this could be better. You should do this conditional in this way, et cetera, et cetera. So it's very, very light touch. You don't have to do a lot. PHP code sniffer will also, if you want it to, can actually rewrite your code to a certain extent to actually help you comply with those standards. There's a thing that we use in VIP called VIP Quick Start and VIP Scanner. Quick Start is a development environment. Some of you may have used varying vagrants before. VIP Quick Start is basically VVV but slightly customised. It comes with VIP Scanner. VIP Scanner will scan your code with the PHP code sniffer and WordPress coding standards but then it will also tell you things that are likely to be issues. It will tell you if you've got a really bad query or it'll tell you if you're using things like extracts that might make your code unsafe. You can do your continued integration testing. So you could use things like PHP code sniffer or other tools as you're committing code into a repository to just check that code as you commit it in and tell you flag any issues there. And there's also a tool called WP Enforcer which is pretty neat. It also includes the coding standards and we'll do some other stuff for you. The best kind of code of view in my opinion anyway is manual code of view. So actually getting somebody else to look at your code, getting someone to read your code. So on VIP this is what we do. Every single bit of code that comes into us we review manually. So we've got something stupid like 10 million lines of PHP and 7 million lines of JavaScript that's all been reviewed by a human being. Maybe even me. And that's one of the best ways because you learn then from each other. You learn what each other does and you learn better ways to do things, better approaches to writing code. It helps you to internalise those standards as well. So the more and more you read code and the more and more you see the same things pop up, you fix the same issues, you actually start to just remember those instinctively. So one of the reasons why I've become a better developer since doing code of view as part of my job is because I can write code and I can instantly know to write it in a different way than I might have done before. Because I've internalised those standards of code of view. Anybody want to offer an opinion as to when not to do code of view? No, because trick question, never. I am guilty of not doing code of view sometimes. Even little changes can break a site so just be careful. Finally, we're hiring. If you want to do code of view and come a better developer then come and join VIP if you like. Or just go and look at our documentation, have a look at the code standards that we hold our clients to and you'll hopefully make your sites more scalable and safer. That's me, thank you. Good morning everybody. My mayor's talk today about why switching to WordPress code standards will ultimately make you a better developer and increase the quality of the code that you're writing. I'm a senior front-end and WordPress engineer at MateDo. We're very proud to be sponsoring this event for the third time. That's my blog and you can catch me on Twitter. A bit about me and my story with coding standards. I've used a little bit of some standards like PSR2 in the past. Never really stuck, moved on from that quite quickly. I'm quite OCD when it comes to things digital really. So I like structure, to have something to stick to, something that's nice and predictable. I've started to work more on team projects a lot more. At my previous agency, I was very much responsible for the whole life cycle of the site. There's very rarely I'd be involved in large team projects, but now at MateDo that's changed an awful lot. I've moved into writing plugins and I'm trying to contribute to CORE an awful lot more now. So I'm a lot more conscious about the quality of my code and how other people are going to perceive my code. At MateDo, we work with an awful lot of external agencies for designer marketing. So again, we're more conscious about the product that we're handing over. That's got to be good quality and they need to be able to get back into that at a later date. So that's something we're aware of. I switched for PHP back in September last year, so I'm still a fairly recent convert to coding standards myself. So what are they? Ultimately, they're rules that your coach should conform to and will be checked against. There's four language-specific standards, so you've got PHP, HTML, CSS and JavaScript. Pleased to say that accessibility coding standards have just landed recently. So with that, it's not so much just one language, it's just the whole site, the plugin, looking at ways to make sure it's more WCAG compliant. Developed for WordPress CORE, official themes and plugins, that was the initial goal of the coding standards. And they've been written by the community for the community, so this is not just one person or one organisation. It's just like, here's the standards, everybody's chipped in a little bit. What surprised me was they've actually existed in some form or other since 2009. Again, I'm quite late to the party here, but I really thought they might have only been around for a year or two, but they've been around for a lot longer than I thought. So what are they not? They're not just for the hardcore. You don't have to have mastery over all the code that's in front of you to use these. Any of us can be using coding standards. They're not just for core contributors. Okay, that might have been the initial target audience for these standards, but any developer doing any kind of WordPress work can be using these standards. It's not a definition of right and wrong. It is just the WordPress way. This is how we do it. While it's open to a debate to a degree, there's no point really arguing these are the standards. That's the way that you code with them. Get on with it and start writing more code. They're not there to make you feel guilty, so you might get a couple of indents incorrect, or you might miss some spacing in a file. It's going to happen first couple of weeks, so I found it quite difficult switching, because I'm used to doing things one way, admittedly, slightly more messy way, but you get there in the end, but it's not to guilt trick people. It's just to provide more of a structure. It's not going to add more complexity to your code. I've actually found in certain situations it's removed complexity in places, which I think is really good. There are just 10 benefits of switching. From my point of view, there are many benefits of switching over, but I just want to run through 10 of my own. Reduce stress. I'm not thinking about it anymore. I'm not worrying. I'm actually writing more code as a result of being less stressed about it. It's more readable. The indentation, the spacing, the structure, naming of things, so much more. It's just so consistent and makes it so much more readable. Much better for teams. All your code is going to look the same. When it was, there's no individual developer's fingerprints. We've all got our little bits and pieces that we do. They're going to be gone. Everybody's singing from the same hym sheet. It's the same code no matter what. Future proofing. So deprecated functions, ignore them. You're always reminded to use new or alternative versions. That's good because if a function is taken out of WordPress and a few releases time and you're still using it then, that's a major issue that you're going to have to rectify then. So this way it's protecting you from that. Faster debugging. So as a result of the code being more readable and easier to scan through, you're going to get to those bugs quicker. You're going to find that line in that error, that notice that you got on the home page. You're going to be able to get to that, suss it out more quickly. It's easier to read and understand, so you can actually be a lot more productive when you're debugging. Things like Yoda conditions are a good example of avoiding really pesky bugs. Typically you would have the constant on the right, the variable on the left, but if you omit one of the equal signs in that, then it's just going to be truthy. It's going to be a silent bug that you might take a little while to actually find. So this way you'll actually get an error if you miss an equal sign here because obviously the expression won't work the way it should do. Better inline documentation as well. So you're always encouraged to be consistent, even little things like full stops at the end of inline comment lines. It's really nice. As a result you're going to have much more detailed documentation of your code, which is great for you and it's great for everybody else working on the project. The code is going to be more secure. It's more consistent validation, sanitisation and escaping of the input and the output. So you'll have no shocks, no surprises. Escape all the things, kind of mentality. It is really good. Better database queries because instead of using WPDB, it's always going to encourage you to use WordPress API functions and classes like WP query. Why not leverage existing caching and performance optimisation benefits? Do that. Don't try and touch the database directly when there are many other ways for you to actually do that. The code is a lot easier to maintain. Certainly in the world of open source. If you can put the code down, walk away from the project and know that in three years' time somebody can download the GitHub repo and it's wonderful to read. It matches the standards that they know and love. It's really good for people working on projects in the present but also in the future. I'm just going to briefly touch on what you would need to do to switch for PHP, to sniff the PHP. You need to get, as Phil touched on, PHP co-sniffer. You'd install PHP.cs on your machine. You can use Pair or Composer. If you're on a Mac, you've got Homebrew as an option for that as well. Then you would just add the path to that PHP.cs command on the system to your global path. That means it's in a global installation that you can use across the system. Get the coding standards rules from GitHub. You can get them from using Git, Pair or Composer or if you just fancy downloading them. You can do that the old-fashioned way. Pop them in a suitable directory. I put mine on a dot folder in my user slash daty green on my Mac, so it's hidden away. Very little chance I'm going to delete that folder accidentally and it's a nice and centralized location. Decent code editor. A couple of examples here. I swear by Sublime. Colleagues that make do use Atom, but all of them will have some support, whether it be a plugin or baked in. Just find something that has that plugin ecosystem where you can download something or actually has it. I think PHP Storm has it baked in at the box, which is useful. Then just configure PHP Code Sniffer. Once you've set that up, you've pointed it to where your rules live on your drive. There's various options. You can check on save. You can actually change the way that the errors are made available to you. I just have mine in the taskbar at the bottom, but you can have much more visible, a drop-down that shows you all the errors on the page. As Phil touched on, there are ways in Coesnith where some of the issues that you face can actually be resolved automatically for you. That's a little bit more fiddly to set up, but once it's there, it's a dream to use. Just a quick example of the output. Some basic code here. These are actual messages that will come out. There's no full stop on the inline comment. There should be one space after the if keyword. The parenthesis. There's no space before and after. Yoda condition needs to be used there, so that needs to be reversed to avoid those pesky bugs that are touched on. There should be an extra space before the closing bracket on the third line there. It's just a sample of what the output would be, really. A couple of useful resources. There's the core handbook on coding standards, and then the get-hold repos, really, for PHP Code Sniffer and for coding standards themselves. Just a comment to wrap up. From my point of view, switching to WordPress coding standards has done more than anything else in recent memory to improve the overall quality of the WordPress code I write. I wish I'd switched earlier, and I encourage you all to switch now and root the benefits. Thank you for your time. Hello. Can you hear me? Good morning, everyone. For all the front-end developers in here who thought they were going to get a SASS, Stiley SASS talk, I'm sorry. I'm talking about Software as a Service. So, yes. Can you hear okay? Yes. So, yeah, the dirty part of WordPress, making money out of it. So, last year I moved our agency towards building a product rather than doing client work, and I'm going to be talking about our journey in creating a product, why we chose to create a product, why we chose SASS, and why WordPress is a good platform for building a SASS product. So, I'm going to press space bar. Yeah, there we go. That's me. That's the new product we got, and that's my Twitter, RaisinCo, so feel free to flower with me with lots of lovely tweets. Okay, so, why build a product? The simple answer is scalable. So, it was always a desire of mine to build a more scalable business rather than selling my hours. So, it started out life as a plug-in on the WordPress repository, and I'm going to talk about the journey from repository to its own self-hosted install as a WordPress. So, the problems I had with the repository are three-fold, really. The first is, in an early stage of building a product, it's very hard to know exactly what your product should look like. You make a lot of assumptions and you make a lot of guesswork. Very informed guesswork, mind you, but you're making a lot of guesses, and you need that feedback loop so you can really find product-market fit with what you've created. I found on the repository it quite hard to generate any feedback because there aren't many mechanisms by which you can contact the people who are installing your product. So, if you've got a plug-in in there, you can't capture their emails and you can't integrate any chat system to talk to them, not that I'm aware of, and I think it's against the repository rules. So, once we bid our plug-in out in the wild, it was very hard to say, hey, guys, what do you think of it? What do you like? What don't you like? So, this was our... That was the first version of the plug-in in WordPress in the repository for free. We bid it out for free on the repository because we knew we wanted this feedback period so we could iterate and learn what worked and what didn't work. So, that was the first problem with the repo. The second one is updates. Now, the repository does give you some information about the usage of your plug-in. We can see how many installs we have, but it also tells you which version people are using. We can see that a lot of people weren't updating and it's really frustrating, especially in these early stages. We've got this idea for a product, we want to put it out there. You're getting lots of feedback or you're trying to get feedback and you make a change and nobody's changing, nobody's using the new work, so that was quite frustrating. Even... Yeah, so nobody updates, really. Well, they do, but 40% didn't. Maybe they installed it once and never used it again. Again, you can't get any insight on the repository into how people are using your product, your plug-in. So, that was a bit frustrating. The third one I mentioned is gathering people's information for feedback, also for marketing. You've got this idea, you've got this embryonic business. You want to get some more traction on it. You can't gather those email addresses and that contact with the user. It's hard to market your product. It all led us to moving away from the repository and building it as a self-installed WordPress site so somebody would log in, create an account and use what we have built. All those reasons I just mentioned about the problems with the repository are also the reasons why it was good to have a SaaS because we could get that feedback straight away. We could push an update and it would just be live. I wish we had really foregone the repository route because refactoring the code to work on a self-installed with multiple users was a lot more development. Hayhoe life's all about learning. This is what it looks like now. Completely different because we got a lot of feedback about what worked and what didn't work. Once we're on the SaaS, because we capture people's logins at the beginning, we can then learn and use that to contact them and start an onboarding process, which we couldn't do with the repository. We send a series of emails out saying what do you like, what don't you like. That helped us refine our product offering. The other reason why SaaS worked out really well for us is the integrations that we could do. Wordpress, as you know, has got such a great ecosystem that many of the services out there will have an existing integration. We could plug in to some fantastic tools and services out there that give us better insight. If we wanted to see how people were using it, we could plug in to the services and how people were using it. We could plug in to fullstory.com, which gave you session capturing, or you could do hotjar, which lets you capture the screen clicks in the, what's the word, heat map. That was really useful to get some insight into user behaviour. Okey dokey, hold on a sec. I think the final point I want to talk about is why use WordPress. The lazy reason we use WordPress is because we're WordPress developers. But really we shouldn't have just jumped into WordPress just because that's what we knew. If you're going to go and build a SaaS business, you should look at all the available options and choose one based on that. But WordPress is fantastic for accelerating your development process because it already has built in a lot of functionality. We had user registrations, we had e-commerce functionality which we required, so we could just pick these different modules and requirements that we had, and that were already out of the box in WordPress and helped us massively accelerate our development programme. It was a really fantastic platform to build a SaaS on. I highly recommend it if anyone has ideas to build a subscription site of any sort, or an online business, then WordPress is really helpful in that respect. Finally, I'm going to give a plug out to the post status podcast who recently did a podcast on SaaS and using it with WordPress, and you can get a much more insightful understanding about the pros and cons from that talk, where they talk about that as well. So, yeah, thank you. So just go ahead and raise your hand if you have a question for one of our three speakers and we have a mic runner who will come around. Hello. I want to ask earlier, the dashboard that you showed us just then, is that a customised version of the WordPress dashboard, or is it a new dashboard using the REST API? Neither. It is a front-end dashboard, so we built a module for the front-end of WordPress, and it does lots of things, it integrates with Google Analytics and helps stores understand their data, but it's all on the front-end of WordPress, so you log in to the site and, as a user, you would never touch the back-end of WordPress. You wouldn't know it was WordPress. That's the idea. Yes, first, thanks for the talks. My question is on the coding standards. So, I know, I think it was some time ago now, I looked at the Codex, but the Codex didn't match the coding standards. Do you know if you all were looking for people to update the Codex to match those standards? I mean, coming in as a newbie, we end up writing not in the standards by default if you just follow those. Too sure on that. I think there's some efforts to improve the Codex side of things at the minute, but, yes, I'm not 100% on that. Sorry, not the best of answers. So, thanks again for the talks. Elliot, I was just curious, you, so Yogo looks like it integrates for WooCommerce customers. Is that what you used for actually building your SaaS product, or did you use something else? Yeah, we use WooCommerce in our site. It's really good, and it's what we know, and it's also really adaptable, so it's a good plug-in to use. My first question was, it was answered, it was why to flip the conditions, the Yoda conditions, but you answered that. So, thanks, because there was an argument at work there. I can now go back, and he said it's wrong, and I said, well, I'm not too sure the whole core would have been flipped, because it's wrong, so thanks. The second question was about the reviewing process that you were saying. Just recommendations on, if I'm reviewing something else's code, obviously I'll be making changes to it. How do you feel that back is a different kind of commission? How do I... What process do you use, basically? I guess it kind of depends... I guess it kind of depends what... You don't have to make that process yourself, so the way we do it is that we get code submitted. So there's two ways we get code submitted, there's like a theme up or whatever. Or they commit code into repository and we review commits individually, and what we do then is we feed back. So we actually say to the developer, this code should probably change because of this, this is the relevant standard, or this is the relevant documentation, then the developer will change it and we'll review it again, and that's how the process works for us. It's probably better that if you're doing code review to actually do it that way so that you've got the developer, the original developer is actually changing their code because that's a better way to learn. If you've got to change your code, then you're more likely to absorb that in and take that in as a thing that you've then learned, you're more likely to absorb that. Rather than me as a reviewer changing your code for you, you're never going to learn. It's like you handing your essay into a teacher and your teacher changing it. That's not going to help you learn. You learn better by just going through that process and doing it because you're unlikely to do that again because it delays you deploying your code and everything. I'd suggest that the way to do it is actually to feed that back directly and have the developer change it. So it's more of a feedback process rather than just going in and changing? Yeah, definitely. Great, thanks. Any more questions? Still have some time? I mostly just do them and don't touch plugins at all, but in Sublime, obviously you've got PHP, Lint and so on, but is there ever going to be, or is there already, an add-in for Sublime that we can use for WordPress standards? Sorry, my area is a little bit bad. Could you just repeat that a bit louder? Sorry, for in Sublime, Sublime Text, is there a plugin that we can use equivalent to the likes of PHP, Lint that we can use specifically for WordPress standards? From what I've seen, there's no WordPress-specific plugin that you can install and that's it. Everything's out of the box. To be honest, I've not looked for a couple of months. I've got a few different apps in there or plugins rather. I've got Sublime, CodeIntel, Lint, CodeSniff, so I've got a bit of a mismash of different things, but if there isn't one that just makes it work out of the box, then there certainly needs to be. It's more for theme and standards for the check after you've created a theme that you can do some sort of review on up there. I've not seen anything on that. One last question. Hi, on the coding standards side, is there anything that you can automatically tie in to do security checks or would that be covered by general code standards? In terms of the sanitisation and validisation? Just craziness that you might put in there. All sorts of things, really. They used to be WP secure. You kind of load things on or scan your whole site. I've not used anything that's automatically done that. I just base it on the errors repeatedly telling me you forgot to escape this, you forgot to sanitise that, but I've not gone beyond that stage to add anything that automates that side of it any more, really. It's a good point, actually, if there's something out there. There are a few things a lot of the time. It can be a bit more nuanced. It's harder to check security issues with automated code review because sometimes it might be. I can't think of a good example. You kind of have to understand the code and what it's doing and realise that actually that variable just there, the way that variable is formed, it might contain user input and you haven't sanitised it properly and you're only really going to know that by looking at the code and reading it it all might not know that that's coming from user input and that it obviously needs to be sanitised. I think you're more likely to need to do manual code review for those kind of things but I'm sure there is a decent amount of automated stuff that will catch some things but you want to look at it manually for security stuff. Slightly more of an addition to the last one. If you install the word press coding standards for PHP code sniffer it does come with a handful of other coding standards as well which extend it and one of those is the VIP coding standards and while as Phil just said you can't automate the detection of escaping that's been missed and things like that the coding standards will the VIP version will attempt to do it and will catch some of them if not all so you still need to read through but for example I'm in supply when I save something and it's a file I'm not familiar with sometimes it will say you outputted something and we expected an escaping function but we didn't see one instead we saw this or we were expecting WP on slash here but we didn't see it you might want to take another look and go through it but I think another one maybe partially just to kind of pick Phil's brains in terms of how he sends feedback I can be rather sarcastic at times and if anybody's seen my Instagram I've probably had a little bit too much bubbly which is not good when you've done a review and you then have to send feedback and the client is a big company and you don't want to offend them what kind of strategy do you use to write up feedback and make sure that you don't end up saying something untoward because reading code and deciding that this is not good and this isn't good enough for someone that the code is terrible and awful and stuff the consequences how do you get around that and being polite and nice and very politely telling them no I just write your code is terrible, please fix it or more code is terrible by the way that invoice is still outstanding it's a good one it's a good point because as developers we spend a lot of time writing code and we take a lot of pride over our work and what we do so if someone turns around and says actually that's not so great that can be a hard pill to swallow so it's really important if you are doing code review someone is the language you use and the way that you give that feedback is you're not criticising the developer the developer isn't bad the developer isn't a bad person for writing this particular bit of code that might have an issue the code is the problem the code isn't doing perhaps what it needs to do or perhaps isn't doing it in the right way so it's important to use language that reflects that so if there's a Yoda condition or not a Yoda condition for example and it needs to be then you say this condition here would be better off as a Yoda condition so you're not saying anything about the developer you're not saying you've done this condition wrong you're saying that actually that would be better off like this you're not saying it should be you're not saying you must do this you're not telling them what to do you're suggesting that the code would be better if this were to be the case it can be really difficult to get that right and actually that's a lot of what me and Tom do every day is to make sure that we are talking to developers in the most helpful way possible it plays into the learning as well cos we're constantly talking to developers about how it could be better and actually helping them to learn from that to improve their code so that they don't have to wait even longer for their code to be deployed because there's issues with it We are going to have a short break we have about 30 minutes you can go get some more coffee I imagine our speakers will be making themselves available some more questions and want to talk to them your closest and best bet for coffee is in the graduate center so the middle building and we'll see you back here at 10.50 if I'm not mistaken for Julie