 I'm the CTO at Pokioke Design. I'm doing web application development since the days of HTML 1.0, Pearl 3, and CGI when web pages were first painted on cable walls. And over the years, I've learned some things that I will try to share with you in the next 10 minutes. And at Pokioke Design, we do work in WordPress. We also do work in Ruby on Rails. And those are two very different platforms using two very different languages. But there are techniques and approaches that really apply across languages, across platforms. And really, that's what I'm here to talk to you about. So that might sound nice, clean code. But I have a deadline. I don't have time for clean code. So we run into this all the time. We're under deadline pressure. Our project managers, our clients, are telling us, we've got to get this done by Friday. You're working long hours. And the common outcome of this is the big ball of mud code, the fast and dirty code to get something done. So we rush to go faster. But what happens is we actually end up going slower. There are more bugs. We have to go back and fix them. We're finding needles and haystacks. Getting the work done actually takes longer than if we adjust written clean code to begin with. So really, the idea here is that an ounce of prevention is worth a pound of cure. So how do we know this? There's actually been studies that have done. Studies that have been done. Watching actually programmers work, how are they spending their time? And the ratio of time spent reading code versus writing is well over 10 to 1. People are actually spending most of their time scrolling up and down in a file looking for something. No, it's not their open another file. Oh, it's not there either. Where is this thing I'm trying to fix? The actual time you spend typing is a lot less than the time you spend just looking around. So if you take the time to make your code easy to read, you will make the code easier to write. There's a great quote from Douglas Crockford, who was one of the people who created JSON. He said, we like to think we spend our time power typing, but we actually spend most of our time staring into the abyss. And this is what I was just talking about. We spend a lot of our time fighting the messy code. So with that as an explanation as to why it's important, here are 10 quick tips for making your code clean. Number one, you are responsible for the quality of your code, not your client, not your boss. If you think about other professions, doctors, lawyers, accountants, they all have professional standards that they adhere to. You don't go to the doctor and say, you know what doc, I'm in a hurry. Why don't you just skip washing your hands? You don't go to your accountant and say, why don't you just skip the double injury bookkeeping? Why are you bothering with that? Let's go. We have certain respect for people in these professions and respect how they work. So if we want to be treated as professionals, we have to act like professionals. We have to be advocates for the quality of the code that we write and advocate for doing it the right way and not accept the option to do it the wrong way. We're a young field and to me that's very exciting to be part of defining what these professional standards are. And it's up to us to create them, not our clients, not our project managers. So that's number one. Number two, when you're writing your code, use meaningful names. So for example, with variables, this is an example of a variable name that's not very good. $1.90, what does that mean? By itself, you've got a little comment. It tells you what it does. But once you start getting to the code, looking at all these variables with all these cryptic names, the mental translating you have to do going back and forth between some cryptic little symbol and its actual meaning starts to get in the way of actually understanding the work that you're trying to do. So here are some better names that actually tell you what the variable does. Grady Butch, the former chief scientist at IBM, said that clean code should read like well-written pros. So if you look at variable names like this, the variable names, those are your nouns in your pros. Number three, we get to our verbs, writing code that expresses intent. These are our functions, our methods if you're object-oriented programming. I don't know if you can see the code on the screen there. It's probably a little small. But the idea here is that we have method names just like our variable names that clearly explain what it's for. And as you read the code, you can sort of understand what it's doing. And I'm not even giving you any context. You don't know what class this came from. But you can read it and sort of get a sense of what's going on. And you can do that without something. There's something that's not here. And the thing that's not here is comments. So this will be kind of a controversial comment on comments. But comments are often lies waiting to happen. Code should speak for itself whenever possible. So what do I mean by this? Often we write comments because the intention of the code isn't clear. So we think, OK, let's write a comment to help explain it. But when you create the comment, you've now written something else that you have to maintain in addition to the code. And what often happens when people are working on a project, they come in and they fix a bug. They update the code. Maybe they don't notice the comment. Now the comment's wrong. And now it's a lie. And it's going to take a future developer down the wrong path when they come down and look at this. So I'm not saying never write comments. Often they are important. For example, if you're dealing with a third-party API and you need to explain some behavior, you can't necessarily do that in the code. So there are good cases for writing comments. I'm not saying never use them. What I am saying is when you're about to write a comment, step back and think for a moment and think, can I write code that expresses itself a little better and then maybe I don't have to write a comment? Number five is the Boy Scout rule. In the case of code, when we talk about the Boy Scout rule, we mean leave the code better than you found it. But the Boy Scout, it's leave the campsite better than you found it. So not only am I saying should you write clean code, but if you're going in, working on some existing code, take your new stuff right at well. But take a few minutes and look at the surrounding code. Can I improve a variable name? Can I break up a method that's too big? So instead of the common scenario of bit rot where code just gets messier and messier over time, we can instead have code that gets cleaner and cleaner over time. This is possible. I've worked with people who've done it and it's a great way to work. Number six, a single responsibility principle. This is one of five principles coined by a Bart Martin who actually wrote a book called Clean Code and many of the ideas in my talk come from there. So single responsibility principle is the idea when we're talking about, say, a function or a method that it does one thing, it does it well and it does it only. So what do we mean by that? A good way to think about it is if you're passing four or five arguments to a function, it's probably doing more than one thing. If you think about all those variables you're passing and you're now sort of creating a matrix of possible outcomes, it can be quite large and it can be hard to debug if there's problems with it because there's so many things going on inside it. So that's a good way of getting familiar with this principle when it comes to functions and methods with classes. If you're doing object-oriented programming, what you're looking for is what's called cohesiveness and the idea there is, are most of the methods in the class using most of the properties that all sort of hangs together? If you've got one subset of methods using half the properties and another subset of methods using the other half, you're probably doing more than one thing in that class. Maybe it actually needs to be two classes. So they each have a clear conceptual responsibility when you come to work on the coding and it's clear what they're doing when they have one responsibility as opposed to many. Number seven, write tests. If you saw Carl Alexander's talk yesterday, he did an excellent presentation on this, much deeper dive that I can take in 30 seconds. But there's really two kinds of tests. One type is called integration tests which actually test the functionality of how a user will experience your code. And these have saved me so many times where I've changed something over here and I run the tests and found, what do you know, it broke something over there and it's much better that I find it with my tests than an angry customer finding it two weeks from now. And there are also unit tests which test your functionality in isolation and test driven development is a great way to do this where you first come up with a test and then write your code to pass the test and it leads to better design. I am running out of time, I'm gonna move a little faster, I'm gonna skip number eight and hit you with number nine. Independent architecture, why am I subjecting you to this awful image? This is a quote from Bob Martin, says that software architectures are structures that support the use cases of the system. Frameworks are tools to be used, not architectures to be conformed to. So what's he talking about here? You can think of WordPress as a framework so you can say WordPress is a tool to be used, not an architecture to be conformed to. The idea here is that there are good practices that can be applied across different frameworks and languages. So for example, WordPress plugins that I've written is very clear from looking at the files and the variable names, what functionality this plugin implements and I could even, with a few changes, take it outside of WordPress and use it, my connections to WordPress aren't any greater than they need to be. So the use cases are clear in the plugin as opposed to, so it's not sort of yelling at you that it's a WordPress plugin, it's yelling at you that it's a photo display or something like that. Number 10, practice, practice, practice. Musicians don't only play when they're on stage in front of an audience and really the same thing applies to programming. Do codecots, go to Contributor Day, learn new techniques when you're not performing for a client who's paying you and that's a way you can really improve your skills and I am done, thank you very much.