 So we're talking about improving code through automation. So you might remember, or at least I do when I was in school, that when I tried essays, I used to get my parents to read to it again, so that they would find entire codes and mistakes that I hadn't improved it before I submitted it, so it would get a better mark. And I find that's a bit of a similar thing that we have with code reviews. We ask someone else to have a look at our code and give us feedback to let us know how we've done. So as we're getting started, I'd like you to put your hands up. So how many of you have had your code reviewed before? So half of you. And so I was expecting that others haven't had someone else look over their code before and give them feedback. What about on the other side? How many of you have reviewed code before? Looked at someone else's code and given them feedback about the same amount of time. So I found this tweet on code reviews on Twitter and it goes along with lines of, there's 10 lines of code and the person finds 10 issues. With their 500 lines of code, it looks fine. And this is code review video. Another one is with pull requests. So three files have been changed and then 25 points in the conversation. But when 40 files have changed, then it looks good to me. And I find that it shows a bit of a problem sometimes with code reviews. The problem being that reviewing large changes is difficult. We as humans find it difficult to process large amounts of content and find issues there and then give feedback. But the more smaller chunks, it is easier for us to process. I find that I've done code reviews for themes on workers at work. And when the theme is massive, I have to break it up into chunks and review it over maybe three sessions so that I get all of the issues instead of doing it all in one go. So you may say the solution is to have smaller pull requests. But I think it's only a partial solution because it's not always possible to have really small pull requests. Sometimes you have to make bigger changes and that just takes time to review. So let's have a look at what things are looked at in a code review. So one thing is the code style. So how is a code written? So we've got two examples here. So the first one is in WordPress that uses the WordPress coding standard. You can see the difference with another one which is like following the PSR coding standard. That was the opening brackets at the top. And the WordPress is on the same line and here it's underneath. Or you can see also with the spacing. So when you have an opening bracket, for example here, you don't have a space. But when you're on WordPress, you have a wider space. So these are different ways of having different coding standards. And the important thing here is just to have consistent coding standards that you follow one way and not make some match. Another thing that you can check is for best practices. So we've got an example here. And the first one is a bit of a not so great example where you have nested conditionals. And this means it can be sometimes difficult to understand what's happening when you're reading through the code. Where when you return early, you can read the code more easier and see that if page is false, then you need to return or if it's about page, it's also not true, then you should return false otherwise at the end then you can return true. This is just an example of some best practices. There are others that you may want to follow from PHP or JavaScript. But these are things that I looked at in a code review. Another thing is called compatibility. So how does your code work with other libraries that you've included or depending on? Wonder how many of you have seen an issue like that when you've been writing your code? So you have a fatal error, you've written some code and your code is not compatible. In this example here, the person has not prefixed the function and there's the same function in two different plugins and that is what's causing an issue. And so there's also things like with WordPress that you may want to check in your code that is compatible with different versions that you support. Another thing is documentation. You may say that the code should be self-documenting, that it's clear when you read the code what it is doing, but you may want to add a reason why you're adding this code or what this code is doing. There may be an exception to a rule that you have found out and you've added. But in the future when you come back, you may not remember that anymore. I've had that with me where I've been working on a project. A few months later I had to go back and make some changes and it took me that bit longer to understand how the whole process was working because I've forgotten to add documentation from where the data is coming from, how it's being processed and things like that. Another one is code quality. It's similar to best practices with thinking ahead. How will my code work in the future when I want to extend it, adapt it and extend it? And just thinking a bit in the future of how your technical debt will be broken down and improved on. You may wonder now what's the alternative to code reviews? I think most of you can guess it's robots. Robots can help you. Today we've got self-driving cars and so in your code you can also include automation. You may wonder what the benefits are of having an automated system. One is the scalability. We humans are working 8 hours, 10 hours, 12 hours a day. We get tired. We're not as productive anymore. The quality that we produce after those many hours of working reduces. But that's not the case with robots or automated systems. They provide the same results regardless of how many hours it's been running or working or how much code you give it to process. Another one is consistency. Like we were looking at the coding standards before to this phase after an opening bracket. This is a small change and can be sometimes difficult for us to pick up all every place where this phase might be missing or been forgotten. But an automated system will consistently find each other places where there's a coding standard issue. Another one which you might find a bit strange is Timorale. So I'm not sure how many of you enjoy getting negative feedback. You know, telling you that you've done something wrong and it might be difficult to get that from one of your colleagues who tells you, hey, you've done something wrong or this could be improved. But you don't take it as personally based upon an automated system. If a robot tells you, hey, you can make this improvement here or you can make this change here, it's a way of communicating and sometimes it's difficult to communicate improvement to your colleagues without coming across too negative. But a solution to that sometimes is also to praise them for good code when you do your code reviews. Now, automated systems are not without challenges. Now the problem with an automated system is that it only passes the code. It does not really understand it. As a person, you can read a code, you can read the comments and then understand why they might have done something differently than the standard way of how you've defined it in your coding standards or your best practices. And what this also leads to is sometimes false positives. The code sniffer or the automated system is only looking at that specific piece of code and I cannot see how it fits in globally in your whole process. And sometimes that can give you false positives. An example is like when you're checking for escaping, you might echo a variable out but the automated system may not be able to see that this variable has just been defined a few months further up and it's just a simple stream and there's no security issue requiring it to be escaped. So let me start to look at WordPress itself. So WordPress has three languages that we use mainly. So we've got JavaScript, we've got CSS and we've got PHP. So we're looking at the different tools that you can use to automatically look at the code and give you feedback on it. The first one is called StyleLint. We've got an example here where we're analyzing a piece of code called the style.css and then this is being run in the command line. So you see that style.css has inline 107 an issue where the expected numeric value for form weight is incorrect. It expects a value and a piece of text. So in this case it might have been bold instead of 700 or something. And it's similar with other lines. And so you can go back into your code, for example, and install a little CSS and go and have a look at it and make the corrections and then run the command again near terminal. But StyleLint does not only just run on CSS, it can run on SAS files too. And so you can define the flag syntax, CSS, and then here also WordPress has its own configuration that you can use that parses or analyzes the CSS files. I think less and less people use less, but there's also a flag for when you want to analyze less files too. So to be able to know what configurations to use, you can define them in your package.json. So you define the dependency of StyleLint and then you've got the dependency style in conflict WordPress that is managed by the WordPress coding standards team. And then at the bottom you can define your configurations for StyleLint itself and define which rule sets you want to use and in this case you've got StyleLint conflict WordPress. So the next one is JavaScript. So for JavaScript you can use ESLint. And here I've got another example. I'll go to the command line, give you the result and also this specific file. ESLint is also used by Gutenberg. So if you've been contributing back there, working in JavaScript, you'll see how it's being used there. And similarly with StyleLint you can use package.json to define your dependencies on modules or the nodes and also the configuration files that you have. So you extend WordPress and you use the WordPress rule set. For PHP there's PHP CS and the CS stands for coding standards. And so here I've run in the command line PHP CS on this specific file and I've gotten back a number of errors. And what you can see here at the bottom it says that some of them or one of them can be fixed automatically and that is where you have the X between the brackets that's marked as the one that can be automatically fixed. And we will be looking at that a bit later. For PHP CS we don't use the package.json to define the configuration but PHP CS.xml file. Here I've created a custom rule set for myself which is used. Here I can define extra properties. So like the text domain that we got here from the theme underscores so you can define the text domain that it should be used as underscores. You can also define the minimum WordPress version that you want to support. So here we define 4.0 and so if you're using any deprecated functions that before 4.0 you'll get a notice and then you can fix those and remove them as you don't support versions lower than 4.0. This can be useful for plugins when you're updating them to check that they're not using deprecated functions. At the bottom also there's an option to add support for PHP compatibility. So if you want to check that your plugins are compatible with the latest version of PHP which is 7.2 now you can also add that and then it runs through your code and gives you your feedback. But the problem is there a bit that if you are checking if a function exists that is before 7.2 or something you might get a false positive but you can just look through the code and realize that it's a false positive and then continue. So as I mentioned before that is possible to auto-fix some of these issues. And here I've got three commands. So the first one is to style int. You can use the fixed flag or the command style fmt. And these are just two different ways I think they're moving from one method to another and so each of them do fix a few different things and so it's best to run both commands when you work in your code. For ESLint there's also got a flag. For PHP.cs you've got two options. The first is you get a diff report and that shows all of the changes so you can verify them before you commit them. And another one is just to run the fit changes with PHP, CVF. What you need to think here is that you should have some type of source control on your code. You may have Git or SVM so that you can see the changes before and after you run these fixes because they are not always perfect and they might not make a fix as you want them. And so before you commit the changes or you push them out just verify, go through them to check that everything is in order. So you may wonder how do I use these things in my workflow? So we're having a few examples. I mean one that we've seen before is just using the command line so you enter your code there and you run it on that civic file or those files in a specific folder. So one of the other methods is to use the editor. So do a little demo here so hope you can see this. So you've got a bit of code here and perhaps you're grabbing something and you're copying something and you've forgotten that you've forgotten the coding and then there's an error here so if I'm just going down and I'm not sure where it is I'm going to click on the line and get bounced up here again to see that I've got some code and it's not right. I can add it again and save it and the issue disappears. But that's the same also like if you forget to add a text domain while you're doing a coding and you've forgotten to add it you've gone on and then before you commit it you may want to have a look at it and realise oh, I've forgotten something and you get also a notice here that it's suspected, underscores, forgot nothing. But that also works if you've got another text domain so you've copied some code from another plugin and you've pasted it in and this phpcs will give you a notification in your editor that you haven't got the right one and then you can go back and add it. This is a quick example of how you can use phpcs but this works in any editor it can be sublinely, it doesn't need to be ATOMAC, it was just an example here the cool place is github so you create a pull request and then you can set up a system that automatically runs this linting or these automated systems to go through your code or the code that has been committed and check for any issues and then return them. So in the first example here you can see that this check, Travis check has failed because there might be some issues but in the second one it has passed and here you can see that I have set up different versions of php to run but only on one of them am I going to run the phpcs and that means that it's a lot quicker because these automated systems can sometimes take time and just by running it on one environment in one build you can increase this time reduce the time it takes to run these automated systems there's also here a link when I share the slides afterwards the documentation of the web as coding standards how you can set it up using a CA tools for proper examples here is a small example of a Travis.yaml file that you can use to set up and you can see there in the beginning you've got the SNP if the SNP variable is defined as 1 then these should run otherwise not and this is the first part is just installing all of these different tools and the second part is running them there are a few different projects that have been worked on Juliet they talked last year about the biggest WordPress core patch ever which was committed last year the work was started at work in Europe and was committed last year and this patch was just to bring the WordPress core up to the latest coding standards so that it followed those also the patch only included automated fixes and now people are still working on adding manual fixes where needed to WordPress core so that WordPress core also follows its own coding standards the automatic theme underscores is also looking at how we can include CSS and SAS linting and also then JS linting so that when there's future changes those are automatically checked for before committed Juliet hasn't given a number of talks on PHPCS how you can make it work for you instead of you working for PHPCS which has got them on speaker deck if you want to have a look at them they're really they'll give you a better idea of how you can really use PHPCS to your advantage Stefan Edgar is also part of the WordPress coding standards team he's been working also on Gutenberg on how to get like ES lint and star lint to the latest using the latest versions of WordPress coding standards so what we covered today we covered how it is to do a manual code review and then what are the elements of those the pros and cons of an automated system what tools you can use for CSS JavaScript and how you can integrate those tools in your workflow so what are your next steps what can you do when you leave this room or when you go back to work on Monday so you can install one of these tools locally to try them out you can set up the tool into your editor so that while you're programming while you're writing your code you're getting instant notifications of what you can improve and then you can add a configuration so you might not want to follow all the WordPress coding standards or all of the things that WordPress forces you to do you can change and adapt them as you wish because some of the notifications that you will get might not be compatible with if you're using namespaces or using like PSR with outer loading and things like that so you might want to adjust it so you might want to go into what's best for your project and then you can run the tool like in the command line and you get a whole report of all the different pages all the different files that you have in your project instead of going through them signaling in your editor and then analyze and fix those issues that you have and then hopefully in the future when you work on further projects you always include these automated tools that's for me today