BRAD: Welcome to Apply Filters, the podcast all about WordPress development. I’m your host, Brad Touesnard, and joining me, as usual, is my cohost, Pippin Williamson

PIPPIN: Hello.

BRAD: This is Episode 14 and, in this episode, we’re going to go over a couple of important things to keep in mind when developing for WordPress. Do you want to get started on that, Pippin?

PIPPIN: Sure. So we’ve got a couple of things that we want to cover. And they’re really some of the just general tips and practices that you should be keeping in mind when developing. And these will include things like debug mode, code formatting, and a couple of other things that you may not be quite as familiar with.

Before we jump into that though, why don’t we briefly talk about what we’ve been working on? Brad, do you want to start?

BRAD: Yeah, sure. I was actually testing; a while ago actually, I was testing renewals because the renewals for Migrate WP Pro are coming up, and just testing the system that we had in place. It wasn’t working out. I was trying to fix it, and it still wasn’t working out. So just kind of decided to build my own add-on for WooCommerce to handle our renewals and upgrades. And I just kind of finished that up this week.

PIPPIN: Cool. Did you find — not to get into any nitty-gritty details, but did you just find that the features of the existing system that you were using just weren’t the right features for you, or did you have some other kind of challenge with it?

BRAD: Yeah, I don’t think it was quite designed for some of the things that I wanted to do, like certain calculations about like how it handled upgrades. It wasn’t sending renewal emails quite how I wanted it to. You know?

PIPPIN: Sure.

BRAD: I just — I don’t know. I probably could have got away with it as it was, but I just wasn’t happy with the way it was doing things.

PIPPIN: Well, and you have the ability to build your own, so why not build something that you’re going to be completely happy with?

BRAD: Exactly.

PIPPIN: And in the end, if you’re not happy with it, who are you going to blame beside yourself?

BRAD: Exactly.

PIPPIN: Nice.

BRAD: Yeah, I struggled with it quite a bit actually to get it just right, and so I feel pretty good about it right now. And I feel like this is something that you can’t really skimp on when you’re talking about your business. You know, renewals are super important.

PIPPIN: Definitely. Renewals are huge. I mean, if they’re not something that you’re considering seriously, then please start now.

BRAD: That’s right. Well, what are you working on?

PIPPIN: I’ve had two primary projects over the last week or so. Both of them are Easy Digital Downloads related. One of them is, I started to get — I wanted to get more serious about automatically detecting fraud purchases. So any time that you’re dealing with ecommerce, and I’m sure you’ve run into this as well, fraud can be a very serious issue. You may have a lot of fraud. You may have a little bit of fraud. But basically fraud is a constant. It’s going to happen, either from people having stolen credit cards or stolen PayPal accounts or what have you.

I wanted to get more serious about preventing it and trying to figure out ways to auto-detect it. So myself and some of the other EDD development team have been working on an automated fraud detection system specifically for our store. Later on it might be rolled out to other users as well. But during the purchase process, it runs some checks and looks for likely indications of fraud. And if something is detected, it will actually flag that purchase for moderation and let the site admins know that they need to go in and double-check that this purchase is legitimate or if it’s fraud. And so that’s been pretty cool, and it’s been successful.

BRAD: I had a lot of problems with fraud with WP App Store when I was doing that.

PIPPIN: I bet.

BRAD: But since I’ve moved to using Stripe and PayPal exclusively, I haven’t had any trouble at all. So I don’t know if that —

PIPPIN: Now when you say you haven’t had any trouble, I would assume you mean that you haven’t had problems with lots of fraud. Everyone is going to have fraud to a degree.

BRAD: Right, that’s right.

PIPPIN: Yeah, okay.

BRAD: I’ve had one. It’s almost been a year since we launched.

PIPPIN: Wow!

BRAD: And I’ve only had one instance of fraud.

PIPPIN: That’s amazing!

BRAD: Yeah, and so I thought — I kind of attribute it to Stripe and PayPal, but maybe —

PIPPIN: I mean, Stripe is huge, for sure, especially if you go in and you enable the, like the force it to require the CVV check and the zip code check. I don’t remember what the other options are. Billing address is huge, like making sure that those are all required. But so, anyway, I was working on that.

The other thing that we’re working on was getting a new extension launched for EDD for an integration with Gravity Forms, which is pretty cool. So we released this new extension called Gravity Forms Checkout that allows you, as a site admin, to create purchase forms for any of your projects. So then you can embed those purchase forms anywhere on your site. So instead of like going through the standard EDD checkout process, you would simply fill out the Gravity Form form and that would complete your purchase. It gives you the ability to use all the awesome Gravity Form’s conditional tags, calculation fields, et cetera.

BRAD: Okay.

PIPPIN: So that’s pretty cool.

BRAD: So that would be pretty handy in a scenario where, if you had products that required a bunch of information to be collected with it.

PIPPIN: Yeah, definitely.

BRAD: Like if you were ordering, I don’t know, stationary or letterhead with an address in the letterhead or something.

PIPPIN: And you’d fill in all those details or maybe add options: Do you want this to have all these additional options? Do you want gift-wraps with them? Do you want envelopes with them? Do you want all those? Features like that that you might want to collect is something that this would be very good for, especially then if you need to adjust the final purchase price based on those selections.

BRAD: Cool!

PIPPIN: Yeah, so it’s pretty cool. So that launched today. All right, enough of that. Shall we jump into our first topic?

BRAD: Yeah, for sure.

PIPPIN: All right.

BRAD: This is something that you’ve been banging away at today, is it?

PIPPIN: It’s not something that I addressed today. Well, I guess I kind of did. I tweeted about it this morning, and it actually got quite a bit of attention. The idea is keeping in mind that the WP Content directory and the uploads directory inside of WP Content are not in fact constants. They are not always the same.

I see this a lot with plugins that I review for WordPress.org. People forget or simply don’t know that the WP Content directory is in no way a defined constant. You can change the name of the WP Content directory to be just “content” or “data” or “assets” or anything that you want. And you can also change the location of it.

I see people will hard code in something like homeURL/WPContent/plugins. And it will work on a large number of sites, but it will always break on any site that has ever decided to move that folder. And so that’s something that you should keep in mind, along with the fact that, along with the WP Content directory being able to be moved or renamed, the actual uploads directory as well, like where all your media files go or any file that you upload from within WordPress, that can also be moved.

It does not even have to live inside of WP Content. It can live anywhere it wants. Well, almost anywhere it wants. It has to be relative to the ABSPATH constant. So those are things to keep in mind. Have you ever had to deal with this, Brad?

BRAD: Well, I actually do; I set up all my sites with an alternate content directory. I use Mark Jaquith’s skeleton, Git repo that he has. Yeah, just the way — like he has kind of a default setup of how he sets up his WordPress sites, and I’ve kind of used a variation of that.

For example, the WP Content directory ends up in /content. And then WordPress itself, the entire WordPress Core ends up in /WP. So WordPress Core and the Content directory are at the same level in the directory tree. I really like it.

And, in testing, it’s really good because it doesn’t let me get away with stuff like this. Right? If I, you know, make the mistake of using WP Content directory to get the uploads path, for example, in a plugin or something, my environment will not work. It’ll just pick the wrong location for the uploads directory.

PIPPIN: Sure. There are a couple of ways that you can detect these inside of your plugins pretty easily. First of all, WordPress has a couple of constants that are very useful. There is a constant called uploads, and that constant is what allows you to define the custom uploads directory. So if uploads is defined, that will change the directory for the uploads folder. In your plugin, if you want to know if there’s a customs uploads directory, you can look to see if that constant is defined.

There’s also the WP_CONTENT_DIR constant, as well as WP_CONTENT_URL constant. And those are both constants that will refer to wherever the WP Content folder are.

BRAD: Right.

PIPPIN: One of them —

BRAD: Those are the ones that you define in your WP Config if you do want to move your WP Content folder.

PIPPIN: Right, but they’re also defined even if they’re not defined in the config.

BRAD: True.

PIPPIN: I may be wrong, but I’m pretty sure the uploads constant is only defined if a user defines it. The WP_CONTENT_DIR and WP_CONTENT_URL are defined no matter what.

BRAD: Yes.

PIPPIN: It just depends on the value of those constants. So you can use those three constants to figure out where files should go. Like if you need to determine a custom upload directly like where you are putting a file from a plugin or where you’re reading files from, things like that. I believe there are two other systems as well. Do you want to talk a little bit about those, Brad?

BRAD: Two other — sorry?

PIPPIN: Two other tools that we can use for detecting the uploads directory or the WP_CONTENT_URL and things like that.

BRAD: Yeah. I’ve always used the wp_upload_dir function. Yeah, I always just use that, and I forget about the constants, to be honest, because I feel like it’s — I don’t know. Constants scare me a little bit. I feel like there could be still something I’m missing. There could be still some conditional out there that’s kind of bypassing the constant and determining the uploads folder some other way or something. Yeah, I really like the WP Upload directory function.

PIPPIN: That one is super useful.

BRAD: I can’t remember what it returns. It’s an array, I believe.

PIPPIN: It’s an array of a variety of info. Give me a second. I’ll actually pull it up because I used it pretty recently. It brings in or, sorry, it returns an array that contains — well —

BRAD: Yeah, here it is.

PIPPIN: I don’t know where the thing is at.

BRAD: Path —

PIPPIN: It’s a bunch of information. Like, yeah, the paths to — I think the path, the URL. Oh, it includes the name of the sub-dir, so let’s say that you have your files organized in a year and month. It’ll tell you what the current one is. Since this month is February 2014, it’ll tell you the subdirectory is 2014/02.

BRAD: Yeah.

PIPPIN: Or something like that. So it allows you to figure out exactly where files should be for this point in time, which can be super handy.

BRAD: Yeah.

PIPPIN: The other one, the WP_Filesystem API is super cool.

BRAD: I’ve never used that, actually, I don’t think.

PIPPIN: It’s an API that I’ve only played with, I think, one time. And I will admit it’s a little scary to play with because, by scary — sorry. Scary is not the right word. Let’s say intimidating.

BRAD: [Laugh] Yeah.

PIPPIN: If you go look at some of the tutorials for the Filesystem API, it can be a little intimidating to look at and to understand how it works.

BRAD: Oh, I’ve totally dug right — I did a deep dive on this. I totally know. I was thinking of something else.

PIPPIN: Oh, okay.

BRAD: Yeah.

PIPPIN: But the WP Filesystem, it’s what WordPress uses, actually, internally for like uploading plugins or deleting plugins or modifying them. And basically it’s a really robust way that you can always ensure if WordPress has write access, your plugin can have write access, basically, because any time that a plugin deals with modifying or creating files on the file system, you’re going to run into permission problems. And the WP_Filesystem API is probably the most reliable method to do it.

BRAD: Yeah. I just want to clarify. The WP Filesystem doesn’t actually or it isn’t used for file uploads.

PIPPIN: Right. Your file has to already exist.

BRAD: Well, because when you upload via PHP, it ends up in a temporary directory, and you have to use the PHP function move_uploaded_file, and so the file system is really an abstraction of the file system, and it kind of it’s a wrapper around the kind of base functions. But it also abstracts FTP and SSH, allowing you to use those interfaces to manage the file system that way if you don’t have —

PIPPIN: Yeah.

BRAD: — like basic access. So say for instance your files, you don’t have write access to the files, then you can give FTP credentials, and it will actually log in via FTP and operate on the file that way. So it’s actually a pretty awesome system, and very unique to WordPress as well because I really haven’t seen this in other CMSs that I’ve used.

PIPPIN: Yeah, I haven’t either. It’s definitely a cool system and something that, if you’re working in the file system, you should take a look at, I think.

BRAD: Yeah, for sure.

PIPPIN: I believe you had another note in here that you wanted to include related to a PHP version.

BRAD: Oh, this is just something we came across. Ross McKay actually brought it up, and it’s just this weird bug. So if you’re using PHP, less than 5.3.1 on Windows, and you wanted to call the PHP function “rename” and actually rename a file between devices, so say you were moving it from D drive to C drive, right? You actually can’t do that in PHP.

PIPPIN: Wow!

BRAD: So this is the kind of obscure bugs that you run up against when you’re developing a product for, you know, rather than if you were just developing one site for one system. It’s so much easier, right?

PIPPIN: Yeah, definitely. All right. Shall we move on to our next topic? Still within the realm of things that you should keep in mind when you’re writing your plugins or your themes.

BRAD: Yes.

PIPPIN: And this one is talking about a minified JavaScript in CSS files. So you do a lot with migrating files, especially with your new extension. And I’m sure that you do a lot with like optimizing your site and such. So really quickly, would you say that it’s pretty important for plugin developers and theme developers to ship their code with minified versions of their files?

BRAD: I think it is. I think you need to do that. And I just want to clarify that my product does not copy CSS or JS files.

PIPPIN: That’s true. It doesn’t.

BRAD: Those things should definitely be part of your deployment, your code deployment. But, yeah, you should definitely ship the minified CSS and JS. Do you mean like as part of like a plugin?

PIPPIN: I mean, so let’s say that your plugin has CSS or JavaScript files that it loads either in the admin or in the front end of your website. Should you include minified versions of those files that are loaded by the plugin? So if a user visits your site, and the assets are loaded from your plugin, are they being loaded as a minified version or as the normal version?

BRAD: Yeah. You should definitely have a minified version nowadays, I think.

PIPPIN: Cool. I totally agree. And, honestly, I don’t think there’s a single good argument for why not to do that.

BRAD: Right.

PIPPIN: The only argument that I have heard before and that I think is completely valid is it makes it much harder for developers or advanced users to go in and modify those files in any way. So let’s say that you have a CSS file and it’s minified. And you want to go in, and you want to make some changes to that file. Well, it’s really kind of a pain to un-minify a file. Sure, you can take it and go through a processor that will undo it for you or expand it. But that’s a little bit annoying.

BRAD: Why don’t you just include the source or like the MLS or SAS?

PIPPIN: That was what I was going to — that’s where I was getting at.

BRAD: Oh, sorry.

PIPPIN: I think that’s the —

BRAD: I jumped ahead on you.

PIPPIN: You jumped ahead of me. It’s fine. So I think that’s the only reasonable answer for why you might not like minified files because they can be more difficult to work with. Well, WordPress has this really nifty constant that it defines in the WP Config file — sorry — that you can define in the WP Config file called SCRIPT_DEBUG. And WordPress Core actually uses it to load or determine if it should load the minified files or the full sized files.

So WordPress Core, by default, loads all minified JavaScript and CSS files. But if you define SCRIPT_DEBUG to be true in WP Config, it will load the full versions. And you can use this in your plugins. There’s no reason that you can’t make use of this constant to decide whether your plugin should load a full or minified version.

BRAD: Right.

PIPPIN: Have you ever done this, Brad?

BRAD: I have done this, and we do this in Migrate DB Pro. It checks to see if SCRIPT_DEBUG is on or off, and it adds the .min to the name.

PIPPIN: That’s a super easy trick.

BRAD: Yeah, yeah. It’s really —

PIPPIN: I mean, it’s so easy to implement that it’s kind of one of those, once you realize that you can do this and that you should do that, it’s kind of a no-brainer.

BRAD: Yeah. I mean, to look at, to find an example of this, you don’t have to look any further than WordPress Core itself.

PIPPIN: Yeah.

BRAD: They do the same thing for their own CSS, so just take a look at that and how they’re doing it. Should we talk about — so when you’re developing, what are some of the things that you do that you think other people should be doing and there are definitely people that aren’t doing?

PIPPIN: I think there are a couple of things, aside from what we’ve already mentioned. Number one is getting really familiar with the other Debug constants that are available. Most everybody is familiar with WP_DEBUG and hopefully every single developer — I know this is not actually true — but hopefully every developer is using it during their development periods of their plugins and their themes to help catch things like notices and warnings and other —

BRAD: So that’s the WP_DEBUG constant, right?

PIPPIN: Right.

BRAD: Right.

PIPPIN: Right. WP_DEBUG constant. And it’s super simple. If you type “WP Debug” into Google, you can find a page on the WordPress codex that talks all about it. So if it’s something that you’re not familiar with, go and become familiar with it. Not only will it make your code more reliable, it will make you a better developer, and it might reveal a bunch of problems that you didn’t realize that were there in your code.

The most common symptom would be things like notices, so suddenly if you enabled WP_DEBUG, it will spit out a whole bunch of things where it says PHP notice such-and-such variable undefined, or undefined key. What does it say: undefined key?

BRAD: Yeah.

PIPPIN: Something like that. And so fixing those things is a really good thing to do. And there’s another one on there that, Brad, if you want to explain this one called WP_DEBUG display.

BRAD: Right. Well, you can shut that off, and then it just won’t show anything on the screen.

PIPPIN: What’s that do by default: WP_DEBUG display?

BRAD: If you have it on by default?

PIPPIN: Well, I mean, it’s on by default if you enable Debug.

BRAD: I’m not sure.

PIPPIN: Well, I think it is because if you enable Debug, it shows your errors. If you set Debug display to off, it hides your errors.

BRAD: Yes. Right. Yeah. If you set it to false, Debug, and they don’t show up, then you have to go digging through your PHP error log, I guess, if you want to see your errors. Is that how you do it?

PIPPIN: Usually. Right, so Debug display, basically it’ll make the errors get recorded, but not necessary show them. So they’ll show in your error logs. Another really nifty tool is the Debug Bar plugin. So if you have WP_DEBUG enabled, and then WP_DEBUG display disabled, it will still allow you to see your errors that you have, but it’s just going to hide them behind a little menu. So it’ll give you a big, red button on your page that says, “Hey, there’s errors here. Reveal them.”

BRAD: Right.

PIPPIN: Which is pretty cool.

BRAD: I’ve also heard of people — there’s another constant, WP_DEBUG log, that you can set to true.

PIPPIN: Mm-hmm.

BRAD: And that will just put your errors into a file in your WP Content folder, I think. And so it kind of separates it out from your PHP error log, so you don’t end up with like other sites in there and stuff. I think a lot of people do that as well.

Personally, I like to have stuff display on the screen because I feel, if things are hidden, it’s too risky for me. I might not see them, and it might be too late by the time I do see them.

PIPPIN: That’s one of the nice — I totally agree with you there.

BRAD: I like it — I hate that it breaks the display, and I hate that when I have like other plugins that have been developed without WP_DEBUG on, and have notices coming out that it breaks display, but I just don’t want to take the risk that I’m going to miss a bug, right?

PIPPIN: Definitely. It’s one of the things I really liked about the Debug Bar add-on because it will hide the errors from displaying on your page and maybe breaking your layout or breaking options, but it still makes it very, very clear that you have errors on the page.

BRAD: Right.

PIPPIN: It adds a big, red button up in the toolbar.

BRAD: Yeah. I’ve used that a little bit. And then I just keep going back to —

PIPPIN: Yeah.

BRAD: — to spitting out —

The other thing you might want to try is enabling Xdebug, if you haven’t done that.

PIPPIN: Oh, yeah.

BRAD: So I just reinstalled MAMP Pro on my machine and, by default, it doesn’t have Xdebug enabled. You have to go into MyPHP or php.ini file and uncomment a line at the very bottom.

PIPPIN: Here’s a thing about Xdebug that maybe you know the answer to. I have not been able to figure it out. I’ve never figured out how to enable or disable strict notices. With Xdebug, have you seen it give a hardcore failure on strict notices?

BRAD: I’m not sure what you mean: a hardcore failure.

PIPPIN: For example, if you’re writing an objected oriented, and you have a class that has a static method.

BRAD: Sure.

PIPPIN: And you call that method non-statically.

BRAD: Sure.

PIPPIN: For anyone who is not familiar with that, the syntax to call a static method would be like the class name, colon, colon, the name of the method. But what people do a lot of times is they’ll do the name of the class and then your dash greater than [->] symbol, and then the name of the method, and it works. But if you have strict Debug enabled, it will actually throw a big, nasty error message at you if you do that.

BRAD: Right.

PIPPIN: Which it’s good because it’s not technically a valid way to do it. I mean, it’s not right. But what I’ve never been able to fix out in Xdebug is, I can’t ever figure out how to turn it on or turn it off. So on some systems I’ll have it where Xdebug with strict notices will be on, and it will cause crazy amounts of errors to show up because the vast majority of people don’t have it enabled. But I’ve never been able to figure out how to turn it off.

BRAD: Oh. Strict errors is something that was introduced in PHP 5.4, I believe. And I think you can disable it just using the error reporting PHP function. You know how in WordPress Core it makes a call to error reporting, and depending if you have WP_DEBUG set to true or false, you know, it sets the error reporting more aggressively if you have debugging on, obviously. And I think, like — I don’t recommend hacking Core, but if you went in there and played around a little bit, I think you could get the strict notices to be disabled.

PIPPIN: Sure. I’m not saying that I necessary want to enable them. I just want to know how to do it.

BRAD: Yeah, yeah. Yeah, well, I’ve been seeing a lot of strict notices as well. A lot of plugins haven’t been tested with 5.4, it seems, I think. But something else people should check out is the Developer plugin. It’s a great — I find it’s a great place to get started kind of accumulating tools to do your WordPress development.

PIPPIN: Totally.

BRAD: I think we touched or we already discussed it though in Episode 5, so people should just check out Episode 5 if they want the details on that.

PIPPIN: Yeah, agreed. Let’s see anything else that we want to mention about standard things that you should be doing in your development. I think there’s a really important one that’s really important to me at least. And, Brad, I believe you kind of feel the same way when it comes to coding standards and formatting.

BRAD: Yes, yes.

PIPPIN: Why don’t you tell us a little bit about how you feel about coding standards and formatting?

BRAD: Well, I think it’s super important that you adhere — so I guess the first thing I always put above everything else is consistency. So if I start working on someone else’s code, and they are not, you know, writing things the way I would, I don’t start changing things or writing things my way, you know, in between what they’ve written. I follow whatever standard they seem to be using. I try to keep it consistent, above all else.

And then, in the future, you know, if we want to reformat the whole thing to adhere to some other standard, then so be it. But I always prize consistency above everything else. Is that how you feel, Pippin?

PIPPIN: Absolutely. I think that’s a good way to put some of the reasons behind the WordPress coding standards. There’s a lot of work that’s been going on recently for enforcing coding standards within the WordPress project. What that really means is that as WordPress, as a project as a whole has one set of standards that it should follow regardless of who wrote the particular piece of code in the project. And those coding standards go everything from the way that you space out your code, the way that you align your arguments, the style of brackets that you use, et cetera.

And I think it’s really important in plugins. I think it’s really important in all development. And I think it’s something that people dismiss very easily because it’s not something that is immediately easy to understand or see why it’s so important.

BRAD: Mm-hmm.

PIPPIN: And I think I have a couple of examples. Number one, have you ever tried; have you ever looked at a plugin or a theme or any piece of code — it really doesn’t matter — that was perfectly formatted? And by perfectly formatted, I mean like they’ve gone so far as to align every single variable. They’ve got perfect spacing on everything. And it’s really easy to read, usually. This is assuming, of course, that they have other same coding practices. But it’s really easy to read and follow.

Now take that same example, but flip it, and look at one that has really haphazard formatting. They’ve got line breaks, either tons and tons of extra line breaks or tons of missing line breaks. They’ve got variable names jumbled together. There’s no consistency. And suddenly it’s very difficult to read.

When it becomes very difficult to read, that also means it’s much more difficult to debug. And that’s where I think people fail to realize it. People think, okay, well, the code works, so why does the formatting matter, because the computer doesn’t give a crap about the formatting? But it’s really important that when you or anyone else has to go back to make an enhancement or a bug fix that you’re able to actually understand what’s going on and that you’re able to do it easily. Honestly, I think that’s one of the most important reasons for consistent code formatting and clean formatting.

BRAD: Yeah, absolutely. I mean, yeah, so one of the things, one of the tools that I use to kind of — so say I encounter a file that I worked on three years ago, and my formatting and coding standards weren’t very good then. I’ll just run it through tidy-php is a package that I have installed into some sublime text, and it just magically formats it according to WordPress’ coding standards. I mean, it just takes care of everything. It’ll put the spacing around your parentheses and all that stuff. And so you don’t have to do it.

PIPPIN: It’s really handy.

BRAD: Yeah. You use that as well?

PIPPIN: Yeah, I do.

BRAD: Yeah, super handy.

PIPPIN: I think some people also get irritated with formatting because they think they have to do it manually, and it’s just tedious. Yes, it can be tedious. But if you use a tool like this, it’s literally one keyboard shortcut and you’re done.

BRAD: Exactly.

PIPPIN: So there’s not really an excuse not to do it.

BRAD: Just make sure when you do these formatting changes that you commit it as one commit without any other changes to the code, and you label the commit “updating formatting”, you know, because you don’t want to mix in a bunch of changes with the formatting changes because formatting changes often change every line of code.

PIPPIN: Yep, yep.

BRAD: So it could become difficult to distinguish what’s an actual code change.

PIPPIN: If you realize that you caused a bug there, you’re going to have a hell of a time tracking that down.

BRAD: Exactly. Exactly.

PIPPIN: I think there’s a — go ahead, Brad, and then I have one thing that I want to add before we maybe finish up.

BRAD: Yeah. I was just going to say that I ran into some code lately that it had comments, like comment stubs on everything, so every function had a comment stub. And what I mean by stub is that it’s like the name, the description in the comment was like the name of the function. Right? So if the function was send mail, the description read: send mail. Right?

PIPPIN: Sure.

BRAD: And these were everywhere in the code. And I was just thinking, “Wow! What if there’s a comment in here somewhere that’s actually important? How the heck am I supposed to see it,” right, because you’ve just got all these completely redundant comments everywhere? And so it’s a needle in the haystack to find what’s important out of the comments. So I would say like if you’re commenting your code, don’t just comment for the sake of commenting, please.

PIPPIN: Right.

BRAD: Comment the why, you know, why this is this way. You know, that’s what I want to know.

PIPPIN: Send to header with a comment: this sends it to the header. It’s kind of a like a no-duh statement.

BRAD: Yeah, exactly.

PIPPIN: So on this note with not necessarily code formatting, but coding standards, so there’s a little bit of a difference between formatting and standards. I mean, they go very much hand-in-hand. But also with standards are things like conventions. WordPress Core recently decided to add the requirement that any time you have a conditional statement of any kind that you must use curly braces —

BRAD: Yes.

PIPPIN: — for the opening and the closing. So what you may or may not be aware of, depending on how fluent you are with PHP, and a lot of other languages as well, that, with a conditional statement, a lot of times what you can do is, you can say like if this equals this, and then the next line is what will happen if that condition is true.

BRAD: Yeah.

PIPPIN: And so you don’t actually have to have the curly braces around it.

BRAD: Mm-hmm.

PIPPIN: Well, WordPress Core recently decided to put in a requirement that says every conditional must use curly braces. And a lot of people don’t like it because of the idea that it’s just extra code for no reason. Why use four lines when you can use two.

BRAD: Well, there is —

PIPPIN: And to be fair, it’s actually a perfectly legitimate argument, but —

BRAD: I don’t agree. There is a reason.

PIPPIN: Well, I don’t necessarily agree that it’s a good reason to not do it, but I understand the point.

BRAD: Yeah.

PIPPIN: It’s kind of — it’s just like why use more words than are necessary. But it turns out there’s actually a very, very good reason to use curly braces.

BRAD: [Laugh] Yeah.

PIPPIN: And, Brad, I think you know where I’m going with this.

BRAD: Yeah, I think I do. Yeah.

PIPPIN: So if you paid attention to the news recently, there was a really big security update pushed for iOS and also OS X. And when I say big, I really mean teeny-tiny, like it was one line of code caused this problem. And it turned out to be a security problem with validating SSL certificates. And it was a really big deal because it actually provided a really easy way for someone with the right know-how to hack into a system or to take over your laptop, take over your phone, et cetera. And the bug that caused it was because of a missing curly brace.

The developer at the time, whoever wrote the code, opted to not use curly braces around their conditional statement, and instead of having one line after the conditional, they had two lines. And the second line after was getting executed every single time. And it was basically doing these different checks, and it would have fail statements. And this extra line resulted in failing every single time, even though it wasn’t supposed to. And it caused a giant security problem. So if they had simply had curly braces around their conditional, it never would have happened.

BRAD: Yep. Yep.

PIPPIN: So —

BRAD: I think it was further complicated by the fact that, like, they were both indented, those lines, so —

PIPPIN: Yeah.

BRAD: — easily it looked like, you know —

PIPPIN: It looked fine.

BRAD: Yeah.

PIPPIN: I remember seeing the code, and it seems fine. But, yeah, so the moral of the story is like it really does not hurt to have two extra lines of code in your code base, so use curly braces because it will — aside from preventing glitches like this that are possibly catastrophic, it also just makes it explicitly clear what is and what is not inside of your conditional.

BRAD: Yep. I agree with that policy. And the other thing that it helps with is if someone else comes along and starts adding code, I mean, that’s probably what happened in the Apple situation. Someone else came along, and they added that second line of code there. Right? It wasn’t the original developer, most likely.

PIPPIN: Right.

BRAD: Right? And they just failed to realize, oh, I forgot about the curly braces. I forgot to add those back in. But if they had been there in the beginning, right, the problem probably —

PIPPIN: It would have never been a problem.

BRAD: Yeah, it wouldn’t have happened.

PIPPIN: Yep.

BRAD: I mean, obviously I’m just speculating here.

PIPPIN: Well, sure.

BRAD: But that’s a plausible situation, right?

PIPPIN: Yeah, totally plausible. Yeah. I firmly believe that coding standards for conventions, formatting, et cetera, are really important, especially when you have a project that dozens or hundreds or thousands of people are working on. You want to have — I think your example that you gave a little bit ago is that you want to have consistency. And so if you take the code that someone else has been working on, and you contribute to it, you want your contributions to match because you want it to be one, coherent project. And if there’s no such thing as standards, and you’re just ignoring them, you end up with a jumbled mess that has the signatures of dozens of people or thousands of people on it.

BRAD: Yep, exactly.

PIPPIN: I’d be kind of like creating a piece of artwork where everybody is responsible for painting one little part in their style. It’s probably just not going to work very well.

BRAD: [Laugh] Exactly. That sounds like a disaster.

PIPPIN: Yeah. Well, do you want to wrap us up?

BRAD: Yeah, sure thing. I guess we should mention our sponsor real quick.

PIPPIN: Oh, yeah.

BRAD: Ninja Forms is a great forms plugin for WordPress. Check them out at NinjaForms.com. And anything else, Pippin?

PIPPIN: No. I think that’s pretty much it. If anybody has any questions or comments, feel free to leave them on the show notes.

BRAD: Awesome. Thanks, everybody.

PIPPIN: Thanks.