Two features of PHP that I believe are often overused when it comes to “debugging” are using echo and var_dump. I’ve talked about this in a few different articles around debugging (like in here and here).
And as much as I am a fan of using a debugger, I think it’s also important to implement a type of logging system so that you or your client can go back and review the activity that’s been happening within the system as they or their users have been, you know, using it.
There are two aspects to doing this, though, especially if you’re looking to following the PSR logging interface and they are:
- the rules for the actual logging interface,
- a project that properly implements said logging interface.
So why not tackle both in this post?
Whenever we talk about certain programming concepts, I think it’s important to take a step back out of whatever specifics we’re discussing and look at things in the context of the bigger picture.
Some modules introduce side effects; some don’t. It’s okay.
For example, yesterday I briefly touched on the idea of programming side effects, but I did so when talking about using PSRs. And for those who are simply interested in aspects of programming in a more general sense, it’s important to understand them, too.
Remember, the idea of side effects as stated in PSR-1 is:
A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.
In this post, I’m not so interested in discussing logic with side effects (because there are times where side effects will happen). Instead, I’m more concerned with understanding programming side effects (what they are, what to avoid, and so on).
After all, talking about side effects in one context may mean one thing whereas, in programming, it may mean another.
Yesterday, I talked briefly about a rationale for using PSRs versus the WordPress Coding Standards and the when and why of both. But that doesn’t mean it’s not without its points of confusion especially if you’re just starting with them, right?
By that, I mean: Say you’ve been working with the WordPress Coding Standards for years (because I can relate) and now there’s this whole new set of rules and guidelines to follow. But it’s not like a simple matter of changing some white space and renaming files.
There are other points to follow, and each is outlined in a number, quite literally (PSR-1, PSR-2, and so on), of how something should work.
So when it comes to just the basic coding standards as outlined in PSR-1, what are some problematic areas that we may encounter as WordPress developers?
At this point, I don’t know how many articles I’ve written about the importance of the WordPress Coding Standards (enough to link to them here, here, and here, I guess, which counts for something).
But after doing enough projects for clients and working with developers who are far smarter and familiar with advanced tooling than I am, I’m at a place where I’m opting to start using PSRs in WordPress WordPress development.
Oh the drama, right?
Seriously, though. There are reasons for this, and there are times in which I think the WordPress Coding Standards should still be used, but I’m quickly becoming more convinced that building any modern project on top of WordPress should use more modern PHP tools (which I’ll briefly mention later).