 Welcome, everyone. Quick note, the session we'll be doing this morning is improving code quality with static analysis. The original talk, which was what type of testing is good for me, has been replaced by this one. So we will be talking about a type of testing that's good for everyone. OK, great. So who am I? I've been part of the PHP community since 2003. I'm a senior developer at Digital Bridge in Chicago and back in the States. Our focus is on making a difference for mid-sized companies in the B2B space, particularly for those who are located in the Midwest area in the States. Therese kind of inspired me with this talk yesterday to call out those who have been an inspiration event part of helping make Drupal great. And so I wanted to make a quick note of appreciation for the people who have played some role in inspiring myself. So thank you. And those who aren't listed, you know who you are, and I appreciate you all as well. So who are you? I expect that you are someone who appreciates quality code or you're someone who maybe you're not fully aware of what exactly is the difference between good and bad code. You're in the right session because we'll be talking a little bit about what good quality code is. And our key takeaway today is going to be what exactly is static analysis? And we're going to talk about ways to change your process to improve the quality of work that you all are doing. Before we begin, I want to tell a quick story. So how many of you use spell checkers? You probably do. Your browser has one baked in. If you see a typo in an email or many typos, you probably wonder why they were creating typos. We tend, as humans, we tend to not trust if there's a whole bunch of typos. We expect like there's something going on or what have you. This picture here shows a parking sign that says private parking only. All others will be towed. The word towed is T-O-A-D, which is, of course, the frog, not actually towing your car. We're pretty forgiving. Like we understand this is probably a joke, or if it was a typo, it's pretty funny. There's sort of a legend called typoglycemia that is kind of on this topic. And the general idea is if you switch the letters in the middle of a word, you can switch those around and we'll still understand what it is you're talking about. As you may have seen some articles online that kind of reference this idea, which is really cool. So I've typed here, who needs a spell checker? But all the words are scrambled. You probably read this and knew exactly what I was saying. Well, the problem here is computers aren't so forgiving. So let's go back to 1962. This was when NASA was preparing for their first interplanetary vehicle launch. At that time, it cost about $18.5 million. Today, there would be about $150 million US. What happened during launch is the guidance system was improperly responding to commands sent from ground control, and it was overcorrecting. So what happened is within five minutes of launch, they had to detonate the vehicle for fear that it would land where boats are passing by or in a populated area. The reason for this was actually a transcribing error. See, this is back in 1962. There were people actually writing down equations by hand. And there was an overbar that was missing from one of the equations. So that overbar basically meant to use a smooth value instead of the raw values. So what was happening was the raw values were being sent, the trajectories being over compensated for, and the rocket went off track. This is known as the most expensive hyphen in history. The problem with computers, they do exactly what they're told. No more, no less. This is also one of the brilliant parts. Now let's fast forward to recent times. Those of you who program, I assume most of you work with code to some degree, this is not PHP code here. This is a bit of code from back in September of 2012. These lines of code here were released in iOS and OS X. This was not fixed until 2014. So it took 17 months for this problem here to be resolved. If you know a bit about code, you would know that this would actually be executed like this. In other words, the lines of code after the second go to fail wouldn't be executed. These lines of code are in the context of validating SSL or TLS connections. So what ended up happening is, while this vulnerability was out there, anyone who understood this bug could perform a man-in-the-middle attack. So they could essentially decrypt any SSL or TLS connection happening on Apple devices. A major security flaw. This is how this ties in to what we're going to talk about today is this bug that we just saw could have been caught by static analysis. Some computers, like computer languages like Golang, they already have some compiler-level errors that will trigger for things like unused variables. Or some of them even have opinionated formatting for code. Like Golang also comes with its own formatter and forces you to use curly braces in some cases. The problem with PHP, as most of you all know, is PHP will execute most anything. JavaScript is even worse so. The point today is if you're not using static analysis, you're wasting time. The reason is you're wasting time on things like back and forth on code style. So if you all do code review, you might be sending PRs back and forth or in the Drupal issue queue, we're doing trivial back and forth on, oh, here's a space that you need to insert here. Or we might be doing bug resolution for obvious problems, typos of variables, dead code. Dead code is basically in the go to fail example where you have code that's not even executed. Another example of how we're wasting time is the grind on poor code or complex or highly coupled code. The reality is we don't have time for this. And if we focus on training or if we all just configure editors to do this type of configuration, the reality is we're not perfect. We're going to miss something. So today what we're going to talk about is what is static analysis? We'll talk about some of the things that static analysis can find using real examples. And then lastly, we'll talk through how to adopt continuous inspection or how to adopt static analysis on the projects you're working on. So what is static analysis? Static analysis is essentially anything that you can do, anything you can learn from code without executing it, similar to a spell checker. You don't have to know the content of a legal document to understand that TEH was probably the misspelling of THE. Similar to code, we can do things like this. Let's go back to the go-to fail example. If we were running Drupal's code standard and PHP mess detector on this, we would get a couple of violations triggered by those tools. One example would be that the hash handshake utilizes a go-to statement. PHP mess detectors suggest not using go-tos. Inline control structures are not allowed. This is part of our Drupal coding standard, in part for this reason. Because if you had curly braces, it would become much more apparent that any lines of code preceding that aren't going to be executed. Another one is indenting Drupal coding standards we have standards for indentation. So it would have been much easier to spot this second go-to fail. And there's many more checks that are available. So how is this done? The way static analysis works is essentially, it scans your file system for code, and it looks for patterns. So it's not magic. It's simply looking for these predefined patterns. If you're using an editor like PHPStorm or Sublime that's configured with PHPMD or DrupalCoder, you're probably already using this. What we're going to be talking about, though, is how, as a project, we need to make those checks more visible to the whole project. And we'll show what that means and how to do that later. So tools in the PHP world for static analysis checks, there are many. Here's a couple that are pretty popular. PHP code sniffer. If you use Coder, probably many of you have, Coder is built on PHP code sniffer. There's another one called PHPMessDetector. MessDetector is used for looking for things like calls to static variables or access to globals. Copy and paste detector. If you utilize the dry principle, don't repeat yourself. We can have a tool automatically check for this for us. And then there's PHP lines of code and many others. And there's many others in JavaScript and other languages. So let's try this out. Let's look at a couple examples just to get familiar. So one check I mentioned was global variable access. This bit of code here, the bold line, shows access to the globals in PHP. The problem with this is we can't do things like type verification. We also can't verify that this input is clean. Any other code has access to this global state. Another example would be an unused variable or a method parameter. This one's really useful. Four cases like this. The first line in this method does an assignment of the variable entity, but entity isn't used anywhere. So why is this being called? That's really confusing. The idea is that these checks are to help us write better code. Now, what is clean code? I'll go back to advice from Grandma Beck. This is Kent Beck's grandma. There's a book called Refactoring by Martin Fowler. It's an excellent book, highly recommended. One of the chapters is talking about what is clean code and what are these patterns of good design. And one of the things he says is he goes back to his grandma who says, how do you know when to change a diaper? Well, if it stinks, if the diaper stinks, change it. The same principle applies here. Don't get too hung up on the specifics, just as someone who's passionate about code that's maintainable, easy to work with. If it stinks, if it's hard for us to work with, let's change it. So what can these static analysis tools find? Let's start with a general idea of what do we mean by good code. And I'm going to start with a couple general ideas about what these checks are doing. So readability, for example, how easy is it for you have someone coming out of the project. How easy is it for them to pick up the code, read it, and understand it? If you've seen anyone use single character variables, that's hard to read. It's hard to understand what's going on. Maintainability, how easy is it to bug fix and apply updates? If you're a maintainer of a project and you have to make changes based on bugs that people find, if those bugs are really hard to fix, then it's not maintainable. Extensibility, let's say you have projects that you're inheriting, and the client is asking for a new contact form, let's say. If that's really hard to add that contact form to the site, then it's not extensible. These are common things that we need to do. Security, how vulnerable is it to malicious users? Testability, how easy can we test that the behavior of the code is matching our expectations? And lastly, correctness, or in other words, bugs are technical at that. How efficiently does it meet requirements? So it's easy to write code that meets a requirement, but how efficiently does it do that? There's performance considerations in this. Let's go through a couple examples. And I'll pause in each one. If you have any questions, feel free to shout them out. But let's go back to that first example of global variable access. If you're using a global, it's hard to test because you have no control over the global state. So let's say when you set up this class and you execute do-load-multiple, which is probably gonna be accessed through another public method, you may run into a flaky test. What if another test has already changed that variable? Or what if there's code in between you setting it and the code executing it that's changing it? Another is this isn't sanitizing that input. Don't trust global state or extensibility. There's no abstraction here possible. If you want to subclass this value that's being passed here, you can't because it's just a PHP array. Unused variable or a method parameter. We saw this example earlier. You have no idea what this assignment of get entity is. It could be cruft, but also maybe there's some secondary effect that's happening in get entity and there's actually a really good reason why this is here. And by removing it, you introduce a bug into the system. But the reality is you don't know. Correctness. This might be a bug, right? There might be a reason that entity was assigned and we're actually supposed to do something with it in this method and whoever was coding this just forgot to use it. One quick note on this. So these checks are from PHP mess detector. PHP mess detector has a check for an unused method parameter. This is a problem in Drupal because we use hooks and a lot of times a hook parameter you don't use. So PHP mess detector, we'll talk about this later, but I've actually excluded that from the detector config that I'm using. But it's important to note this because that check is for Liskov substitution principle. So the idea is if you have two classes and you subclass them, they should be doing the same behavior. And if you're not using a parameter in one of your subclasses, it might be an indication that you need to better abstract your code in some way. Dead code. This one's pretty obvious. We talked about this one earlier with the go to fail. The problem is it's obvious to us, but actually finding dead code is kind of difficult. This example here, I pulled, I believe I pulled out of Drupal core, Drupal 8 core. This is a private function that doesn't get called anywhere in this class. So you see this and you ask, why is it here? Was it supposed to be protected so that it can be subclassed? Testability, you can't test this. So if you're trying to verify some behavior of this method, let's say code cut test coverage is an objective for your team, you can't do that. You can do it through some weird reflection, but let's not go there. Correctness. Code that isn't executed is usually a bug. Case in point, go to fail. But this is a really good example because there are false positives. If you're using static analysis, there are going to be cases where it throws a check when it's actually fine. The reality of this code sample here, it's actually a, can't remember if it's a subclass or a parent class, so it's actually calling this. So it's actually fine for this method to not be executed in the class itself because it's being called in one of the subclasses. Number of public methods. How many of you have opened up a class and said, whoa, I have no idea what's going on here? The reason number, so this is an entity type, this comes from Drupal core. There's a total of 69 public methods on the entity type. If you've tried to work your way around an entity type, you know why this is hard. It's hard to understand what all these methods are. Over time, you get used to them. But extensibility, it might be confusing. Let's say you wanted to create a subclass of this and maybe be hard to fully understand what exactly you need to be changing or overriding from the parent class. Correctness, if you have so many methods, it might be an indication that your class is doing more than one thing. There are cases where this is useful. It might be useful to have so many methods on the same class because you wanna encapsulate that complexity in your system into one class. Because the reality is, even if you break it apart, you still have that complexity, and it might be nice to keep it all in one class, but go back to the principle of, if it stinks, change it. We as humans can only understand so many problem spaces at once by dividing up a class and isolating the function of the class. It helps us as humans understand. Computer can understand this just fine. Use of statics. Drupal is not very good at this. So the problem with a static is you can't test it because you can't mock or test double. In this example here, workspace type, you can't create a double for that. So if you wanna test this function called add, this method called add, you would have to ensure that the workspace type class, its static method load multiple. If it has any indirect inputs, like inputs from a database, you would have to figure out somehow to provide a stub or test double in whatever its collaborator is. You can't just test double the workspace type class because it's a static. So testability, it's very difficult to stub or create test doubles for statics. In some cases, it's impossible. Extensibility. You can't replace workspace type with a subclass. This can create problems. There might be a case where you want to use a static if you want to control extensibility. So going back to that first slide we were talking about, what is good code? One of those things, extensible code is nice. There are cases where maybe you wanna control that extensibility. So use a static to force no one to be able to create a subclass, for example. Missing.commit. If you're missing documentation, it's a critical bug. This method is coming from, I believe this is coming from multiversion manager. Multiversion is a contrib module in Drupal 8. You don't know what this is doing. Obviously it's calling doReplication, but why in the world would you have a method called update that then just passes the same parameters to doReplication? It's not immediately obvious. So readability, you pick this up and you wanna remove that method because, oh, this doesn't seem to make sense. It looks like it's just duplicating effort. So you want to remove it, but you can't accurately, without knowing the author's intent. Extensibility, how do you know, if you want to subclass this, how do you know that you've set up the subclass correctly? Because you don't know the author's intent here. Yeah, document your code. In-path complexity or cyclomatic complexity. I'll pause on this one for a minute because the words themselves can sound kind of intimidating. But the basic idea is pretty simple. The idea of in-path complexity or cyclomatic complexity is how complex is the computation in this function, or in the method, in the lines of code being executed? So cyclomatic complexity, I'll start there first. Basically what you do for cyclomatic complexity is count the number of control structures in a function or in the lines of code. Control structures are like if statements, switches, for each loops. The more of those there are, then the more of different paths through the code there are. In-path complexity is a little different. In-path attempts to understand every single individual path through the code. This method here has a cyclomatic complexity of 15 and an in-path complexity of 420. Computers handle this fine. That's not the problem. The problem is us. The problem is the human element of this code. If you pick this up and you need to debug it, it's gonna take you some time. Or if you wanna change its behavior, that will take you some time. Unless you wrote this code, or even if you did write it, and it's a month later, A, you've probably already forgotten your original intention because it's so complex. And B, we might be able to take 420 independent paths. We might be able to hold one or two of those paths in our head, but understanding all 420 at once, nearly impossible, probably impossible. So readability, it's hard to understand so much complexity. It's hard to debug and correctness. If you have so much complexity in a single method, it may be an indication that you're violating the single responsibility principle. So it might be an indication if you see high complexity value, that you may wanna break that code out into multiple methods or functions. Going back to what I said earlier, there might be cases where you wanna encapsulate all that together. I noticed in the Drupal code base, there's an archive tar. If I remember correctly, it's like one file with a whole bunch of code, and it's highly complex. But maybe that's okay, because maybe you just wanna encapsulate all that complexity into one place, because you have it working and you wanna forget about it. Maybe that's the case. But going back to what is good code quality, we have to maintain that. There's eventually gonna be a bug in that archive tar and somebody's gonna have to go and figure out what's happening. It's easier for us to understand if it's not as complex. E-Ferrent and A-Ferrent coupling, I love this metric. Essentially what E-Ferrent and A-Ferrent coupling are is an evaluation of how many other classes know about your class, which is A-Ferrent and then E-Ferrent is how many classes does your class know about? The idea is, take this example here. This is multi-version manager. It knows about 15 other classes. So if any of those, think about it in terms of likelihood of change. If you're aware of 15 classes, there might be a high likelihood that any of those are gonna change. This means that any of those 15 classes might cause this class to have to change its behavior as well. High coupling or close coupling means that anytime you wanna make architecture changes, it's gonna be more difficult because there's more classes that you have to understand how that behavior changes. So extensibility, it's hard to change. Testability, I dare you to try to unit test this. If you try to unit test a class that has 15 other classes, more than likely you're gonna have to create a test double for each one of those classes. And let's say the class has 10 methods that you need to test, that's creating a test double in each of those situations 10 times. That's a lot of work. And correctness, if your class knows about so many other classes, it might be an indication that your class isn't doing just one thing. Now, this is a little unfair because manager classes are kind of the intent for encapsulating some of this complexity. But again, going back to what does code look like that's easy to work with? It looks not like this, it looks like loosely coupled code. So, we've gone through all the examples. There are many more examples we could have gone through, but how do I apply continuous inspection or static analysis to my project? How do you get started today? I recommend a tool out there. It's actually a cloud platform called Code Climate. It's free for open source projects on GitHub. Unfortunately, when they say free for open source projects, what they actually mean is free for GitHub because Drupal, Drupal.org, anything on Drupal.org is GPL, so it's gonna be free open source, but they only support URLs, it's like URL-based, so you have to have a Git URL that's from GitHub, unfortunately. But we'll look at some examples. What I like about Code Climate and the reason I'm gonna use that in some of these examples is because it's just an abstraction of PHPMessDetector, PHPCS, and whatever other static analysis tool you want. Because Code Climate is a platform, if you had your own fancy static analyzer that you wanna use on Code Climate, you can do that. A couple alternatives to Code Climate would be Scrutinizer. Maybe you've seen some projects, you use Scrutinizer, it has like a GPA, et cetera, or you can just run these manually. But again, we'll use Code Climate because I think it encapsulates the idea of workflow really well. Quick notes on how to configure Code Climate. Take a look at github.com slash Joseph D. Purcell slash Code Climate and Drupal. We'll look at the example real quick. Basically, you specify what engines you want, in this case, we're using PHPMessDetector, PHP code sniffer, and then there's a rating section. Code Climate has what's called the GPA. The GPA is essentially a weighted value of how many errors do you have per line of code? And then they exclude pass. You probably wanna exclude config. This is an example of a Drupal project, so you wanna exclude Drupal core so that you can focus just on your own custom code. The second thing I've done is, I've created a modified version of PHPMessDetector config. This is also available on the github project. The reason for doing this is, unfortunately, out of the box, PHPMessDetector more than likely is not gonna be a good fit for you. One reason being, it has camel case checks. Not everybody's using camel case, so I've customized it for that as well as static checks, et cetera. So there are two main ways to use static analysis on a project. One is what's called continuous inspection or basically tying checks of code style or security vulnerabilities or what have you into your development workflow. So every time you check in code, some awareness is brought to you about what violations have been introduced. The other would be what's called a code audit. A code audit would be anytime you pause development for a second and run inspection and take a look at what does the code base look like? Where's the complexity? Are there ways that over time we've introduced maybe some architectural incorrectness? Looking at the first one, this diagram comes from Continuous Integration. It's a book written by Paul DeVall. Very good book. Essentially it's talking about at what point you tie in static analysis into your development workflow. You tie it in when you run your tests. So when you run automated testing, you should also be running inspections. If you're not running static analysis with your tests, then you're missing a critical part of continuous integration and you're wasting time. So what does this look like? Daily workflow would look something like I commit, push my code, automated tests and static analysis run. If the test fail or static analysis has introduced some violations to build fails and whoever was contributing that revises the code. If it succeeds, then code is reviewed and it's merged. Here is a poignant example of why static analysis is so nice. Aidan Feldman over at ATNF, they're using Code Climate on their open source projects. This is what a poor request looks like for him. All checks have passed. This means I don't have to look through any of the code that was introduced for code style violations. I don't have to spend a single second on it because I know that those checks have already been run. That's amazing. Now if there were violations, it would look something like this and you can click on the details button and what's so nice is with Code Climate, it's only showing you violations that were introduced for the code that was committed. If anyone of you have used Gulp or Grunt and tie in ESLint into your build and all those lint violations print out for everybody's code, it can be kind of annoying because somebody else introduced a CSS file that is throwing all these violations. That's not your fault. You're trying to get your work done. What's nice about this is it only shows your violations that you've introduced. So you click on details here and it'll take you and on the right it'll categorize the violations. I mentioned earlier that you're gonna have false positives or yeah, false positives. Code Climate will allow you to silence false positives. Take that dead code example. You could click, there's a button. I think it's the I with the line through it. You can click that and it'll hide that check for all sequential runs. One thing to point out again, the GPA in the top right corner, what's also nice is if someone creates a pull request, you can see a weighted average of how that's affecting your overall code base. I could be a project manager and I look at this and I see that it's decreased our GPA by a whole point. I would throw up my hands and be like, look, like what's going on here? Why is this work that you've done been so incorrect according to the rules that we have established and identified as a development team? So I don't need to, again, like going back to the, I'm proofreading a legal document. I don't need to know anything about the content and if I see a whole bunch of spelling errors, I'll probably ask you about it. Anyone could do this here. So the importance of bringing these static analysis checks out to the whole project team is it's one thing for me to know what violations I've introduced into the code. It's another for us to all be aware of them. The second way that you can use static analysis on a project is a code audit. You might use this for planned refactoring. There's a little bit of a myth that you can iterate from a bicycle to a race car, but the reality is each stage along the way, your architecture, like the fundamentals of the system will need to change. So you might experience high coupling or high complexity in places. Take time on your project to plan for those refactorings. Or you might use this information during sprint retrospectives. So your project manager says, hey, look, I know you guys have been under a lot of pressure. Our GPA is declined by half a point. Can we talk about what it is? Like are they code style violations? If so, maybe we could get an intern to pitch in and help out with those code style. I'm gonna use an example. There's a tool that I haven't mentioned yet called PHP Metrics. Go to phpmetrics.org. Fantastic tool. PHP Metrics will run several, it'll generate several different types of information for you. And it has a really nice graphing tool for you. And they also have some good documentation. If you wanna learn more about these code metrics, PHP Metrics is a good resource for that. I've generated this graph to show a couple of ways in which a code audit might be helpful. On the y-axis or vertical axis, I'm showing cyclomatic complexity. So the further up the y-axis you go, the more complex it is, the harder that code is to understand. Moving along the right on the x-axis, e-frant coupling, this means the more code that this class has to know about. So I've run this on Drupal 8. This is actually a bit dated. I think I ran this several months ago. But what's interesting is, I mentioned Archive TAR earlier. Highly complex, there's no coupling because it's not including any other classes. But if we're gonna talk about places where we might wanna do some refactoring to make it extensible, to make it more readable, that might be a good place to look. How many of you have worked with Entity API? Yes, we have worked with Entity API. How many of you have found it challenging at times? Yes, I assume we have. You know, looking at places where, let's say Drupal 8 has code audits. We can point right here and show where the complexity is. There's several Entity classes right here that come up as they know about a lot of things. Why? Why is that the case? Why is there so much complexity in these methods? These can indicate to us places where we might wanna devote some time. Bring in an architect to dedicate some time. Hey, look, looks like Entity Manager is using 49 other classes. Is there an abstraction we can introduce here? What not to do? Static analysis is, in some ways it's very simple and in other ways it can be really complex. Even just from a human communication point of view. Cause that graph I just showed, if you don't understand what those checks mean, it might be misinterpreted. So, static analysis is only as good as it's configured to be. One of my criticisms of code climate is, at least in my opinion, it doesn't make very clear, don't just run code climate. If you're gonna use code climate, you have to take that code climate YAML and reconfigure it to exclude certain directories and configure the engines to run only the checks that make sense for you and your project. And if you're gonna use PHP Mest Detector or PHP Code Sniffer, take time to edit that config to accommodate whatever your team is, whatever you say is correct code. Static analysis is not a replacement for your brain. Even take complexity, for example. I come to you and I say, hey, there's a complexity of 15 on this method. Go refactor it. No, have a conversation. There might be a really good reason that complexity is there and you may choose to defer that refactoring to another time. You might say, oh, well this sprint, we've introduced that complexity now, we're planning on refactoring later, et cetera. And some indicators are okay. Just because someone creates a pull request and there's 10 new violations, that doesn't necessarily mean it's incorrect code. It means that the checks that you're checking for have been triggered. Now, whether or not those are acceptable, use your brain. Use your own intuition and understanding. Don't compare GPAs of projects that use different configurations. So GPA, again, is kind of like a weighted average of how many errors per lines of code. If two different projects are using different configurations, they're gonna have different violations generated. So those weights are gonna be different. So if you're looking at GPAs, be cognizant of how those GPAs were generated. Don't avoid static analysis because there's too much to tackle. Clean code is hard work. It's hard to take the time and effort to identify something maybe as tedious as writing a code sniffer check for a curly brace. But the reality is, once you've done that work, you can run it repeatedly. It does the heavy lifting for you. We go through a lot of code, especially if you're doing code review if you're a project maintainer. Static analysis is gonna help you in the long run. And don't run static analysis locally. They should be shared just like tests. If you're running automated tests, chances are you have people configured to send alerts to when tests fail. The idea is build awareness of what's happening in the code. Tie in your project manager. They can help you. And hopefully they're supporting you in that if you're under pressure or maybe you're doing some exploratory work, they might be able to help you to give them an indication of you might need more time or maybe you need to change approach. Overall, the cost of owning a mess means that your productivity is gonna decline. So the way that static analysis is gonna help you is it's a tool to help you maintain what is good code for you. This diagram here comes from Robert Martin's book, Clean Code. It's a very good book, I recommend it. The reality is when we write code, there's an entropy to it. Over time, we introduce errors, the architecture of it changes, et cetera. The Linux kernel and Windows server teams are using static analysis on their projects and there was a research paper that was done. And what's interesting, they've found a 50 to 60% correlation between static analysis checks in a given module or file with bug reports that were generated later on. Essentially the idea is these checks aren't just good code, they also have an impact on your users and your stakeholders. The savings of static analysis are you're not wasting time looking for code style. Go back to that poor request example. I didn't even have to look at the code view to know that there weren't any violations introduced. You're not worrying about obvious bugs or typos. You can clean as you go. One of the things that's really difficult in Drupal is we have thousands of tickets open and we want to, you open up a file and there's missing documentation or you change one part of the file to be compliant to coding standards but you're encouraged to not change anything else because you might impact another ticket. Doing something like what code climate is allowing us to do of just checking the one patch can allow us to do clean as you go. And it also exposes during code audits, it exposes the parts that are hard to change. All right, so what's next? I assume you all are excited about static analysis and how it can be of benefit to your projects. There are a couple of things that I see that might benefit us as the Drupal community. One would be agreeing on the static analysis config for D7 and D8 for core, contrived and any projects that are built on Drupal. This is gonna allow us to have, like if we wanted to use GPAs for contrived modules, we could do that. If we standardized on what those PHP mass detector checks are, what is Drupal's threshold for complexity? Our static's okay. Right now, code climate does not support any other domain besides Drupal, or besides GitHub. If they supported Drupal.org, that would allow us to not rely on the Drupal's infrastructure team to have to support this tooling. Code climate could easily do this. Start using static analysis on corn, contrived. There's a ticket out there right now that talks about this. There's not a lot of activity. Go take a look. Add GPAs to compare contrived modules. Right now, when we compare a contrived module, it's usually somebody told you it was a good module or you've used it before and had success or you're just looking at how many downloads it's had and how many open tickets. Using a GPA would be a way, at a glance, we could get some feel for how well does this module adhere to what we're saying is good code in the community. Imagine if every PHP or Drupal vulnerability, security vulnerability, gets a check written for a PHP CS. That's incredible. Automatically, we could run those checks on every module, on every file and core, on every Drupal project that anyone has. We could publish that code sniff and everyone could run it in an automated way to see if their code has a violation. Ruby's Breakman does something similar for this, for the Ruby community. Imagine if we had automated code quality spike tickets for any time it's security vulnerability or project drop below a GPA. This would encourage the Drupal community and projects to pause and take time to go back and maybe decouple code where there's a lot of complexity or you just throw a bunch of classes in a file or in like a manager or something and maybe we could take time to refactor and use these checks in an auto-correct. If you've PHP Storm uses PHP Code Beautifier and Fixer, basically what it does is it takes those very same static analysis checks and in the checks there's a way to say, okay, here's the check and here's how you fix it. So what's kind of cool, imagine down the road, not only could we generate a security vulnerability sniff that goes out, analyzes all of core, all of contrib, all Drupal projects everywhere and it has, here's how you change it. We could do that. Lastly, one idea would be to write a Drupal project analysis engine for Code Climate. I mentioned Code Climate is a platform so you could write your own engines for it. Before we go, static analysis, it's gonna save you time but the reality is, it's up to you to take on the initiative of writing clean code and promoting that. This slide is actually a pitch for another talk that if you know Zendoodles, Andrea Soper, we gave some talks last year on technical debt. It was titled Technical Pollution, Insights from the Lurex. If you know the story of the Lurex, you know the Lurex is talking about, the one story comes in and he's polluting the environment, cutting down all the trees and one of the things he says is the trees have no tongues and the same way Code doesn't have a voice, projects managers, stakeholders, the people who are paying the bills, more than likely they're not understanding the code as well as you are. You are the Lurex. You are the one who's speaking for the code. Don't waste time, you know, prevent Drupal or your project from having the next go to fail. Take time to clean up your code. Thank you. Come to the sprints on Friday. The slides are online. If you want help setting up PHP Mestetector or PHP Codesniffer, whether it's on your own editor or setting up on your project, let me know. You can find me on Twitter at josephdpercell.com or josephdpercell. I'd be happy to take time to do that. I'll also be at the sprints on Friday so we could sit down then. The last slide has some references and reading. Are there any questions? All right. Oh, yes, go ahead. Ah, yes, SonarCube. I have not used SonarCube. It sounds really cool. I hear they have a set of checks just for Drupal. So do you worse checking out SonarCube? I personally haven't. I believe it's a pay for service. It's free? Okay. Ah, I see. Yeah. Really? Yeah. So what it sounds like is SonarCube gives some different types of functionality for prioritizing some of these checks that are found. Yeah, that's cool. I'd heard of SonarCube. I didn't realize it was, it's free for... I mean, you can install it on your server. You can install it on your own server? Okay. Yeah. Well, that's cool. Any other questions, comments? Yeah, so the question is essentially you have, like take Drupal's community, you have thousands of tickets open with patches already out there. So what's the cost of making these changes? This is one of the challenges of community-evolved development. I don't know. What is the impact of not making these fixes? The impact is, as I'm sure you all have experienced is you open up a file and it's like parts of it are inconsistent. So what's the cost of that versus going in and fixing it and having 10 other patches updated? I don't know. I think it's worthwhile. I think that the reason it's being used by Linux Kernel and Windows Server, for example, as well as some community projects is because of that, because it provides value longer term. It reduces the time that the people who don't have time, maintainers, doing review, it reduces the time that they have to spend looking for these problems. So I would pause it, it's worth it, but I have no basis for that. That's interesting, yeah. Incremental need. Okay, so the idea is, yeah, we have 20 checks, but let's start with one. Let's update one and go to the next one. I like that. Yes. So on the Git project, I've actually tried CodeClimate on Core 8.1 and 8.2, as well as some various contrived modules. And then I also tried it out on WordPress, and it was kind of interesting. My initial findings, it doesn't look to me like WordPress, here's to its own code style very well. But, yeah. Ah, October CMS, the built on Laravel? Yeah, it's built on Laravel, yeah. Yes. Like 7 is like a 1.5? Yeah. It's like, oh hey. So the commentary is, if you look at October CMS on CodeClimate, the GPA is very low, which goes back to how is it configured? One of the things I noticed looking at CodeClimate is there's all these open source projects that have CodeClimate ratings out there, at least on CodeClimate site. And then it's like, I don't know that they configured, like some of them I looked at, that had very low GPAs, they didn't configure CodeClimate. So going back to, it's only as good as it's configured to be. So in that regard, I've been a little disappointed by CodeClimate, but I know it's a hard balance of providing this great tool for anyone to use, and then they're not taking the time to use it, right? One of the things that, because I had a conversation with one of the folks that CodeClimate is around, a lot of them have Ruby backgrounds, so they have some really good input on Ruby, and what a base configuration makes sense for Ruby, but they're still working on base configuration for PHP. So right now, it runs all of PHP mess detector checks, which as I mentioned before, it checks for camel case. That doesn't apply to some coding standards. All right, I think that's all the time we have. I'll be around, come find me, find me on Twitter, I'll be at the sprints. Thank you all. Hey, thank you. Can I have a PHP phone? Oh, great.