PHP 101: 01 — Preface: Writing good PHP? (Yes, It’s possible.)

“LOL” you think, “PHP? Seriously?”

PHP gets a weird rap in the web dev world these days. Thousands upon thousands of entities rely on PHP as the bedrock foundation for their website/web application for mission critical, battle tested, reliability and it’s general familiarity. Indeed it still remains to be one of the top most reliable languages in the form of Job Security as most companies who aren’t going anywhere any time soon, use it for one thing or another. It’s indeed not the only, there is .NET and Java competing for roughly similar spaces with varying degrees of grey, and languages like Ruby and Python have made a name for themselves in the web space arena in regards to start up’s and smaller companies. They’re certainly capable as well, Ruby powers GitHub and Python powers Patreon, and Node powers chunks of Walmart. But there is no use denying, that PHP powers an incredibly large portion of the web.

So why does it garner a knee jerk reaction when people even throw the name around? One word: Legacy.

See, PHP is a unique beast that takes a lot of inspiration from other languages like C/C++, and through the years has been taking ideas found elsewhere and sticking them into the next version of the language. It is a Multi-Paradigm Duck Type Language that started in the woodwork with no apparent rules or real established guidelines of approach in terms of it’s own design and that translates very literally to how it’s written on the web. In other words: It’s kind of a mess.

A big mess. Internally, the built-in functions don’t appear to make much consistent sense. For example, between an Associative Array (Dictionary/HashMap) and an Object, if you want to check if a hash or a property exists respectively, you’re in luck because PHP has you covered, except someone checked out to lunch a little early when designing the functions. To check an array for a keys existence, you use: array_key_exists($needle, $haystack);, to check if a property exists in an object you use property_exists($haystack, $needle);. It should be fairly obvious how unless you used an IDE that reminded you of the arguments up front, how one could forget the argument order.

Additionally, due to the multi-paradigm nature, a PHP script can be written in not just a myriad of ways, but styles can be (and historically have been) intermixed with each other. I'm working on a legacy script right now, that mixes classic PHP4 functional with newer age PHP5 OOP and it’s a freaking nightmare.

One of the big core problems has always been it’s anarchic attitude towards design, implementation, and execution as a writer of PHP. Languages like Python live, breathe, and die by a pre-defined official style guide (PEP-8) to write Python code in, and any IDE worth it’s salt dealing with Python (like JetBrains wonderful PyCharm) will actively start complaining to you if you so much as space things differently than the style guide wants. PHP has never, and still officially doesn't have, anything like this.

But ultimately, the notion that it’s somehow inherently impossible to write good, clean, readable, and structurally wonderful PHP code; is a major misconception. The PHP community has really come together as of late to start cracking down on PHP’s legacy shortcomings and come up with solutions that near anybody can use at any time (even in legacy code). Some of the biggest advancements in the PHP atmosphere are still fairly recent, but the strides they've made have been earth shattering.

First and foremost, I would like to present PHP-FIG. This is a spot on the internet that proposes and defines unofficial rules and guides for anything powered by PHP to follow, to improve the consistency, the ecosystem, and the general overall maintainable health of a php powered thing. You may have seen the term “PSR” kicking around a lot lately, and this is the origin of it. The PSR stands for “PHP Standard Recommendation” and each recommendation is proposed, voted on, and defined by the collective group devoted to PHP-FIG, which happens to be a collection of individuals creating/maintaining the frameworks and tools of php’s tomorrow.

The PSR may be officially unofficial, but the groundwork has been laid by these people that shape the way modern PHP applications are written and compiled. PSR-1 and PSR-2 are PHP style guides, PSR-0 and PSR-4 are Namespace based Autoloader standards, and PSR-7 is a standard on server side calls to http services (like APIs) that libraries like GuzzleHttp/Guzzle adhere to.

The FIG does some wonderful stuff, but its influence doesn’t stop at just a standard joe schmo web dev level, the PSR’s have really taken off when implemented by some of the largest and/or most popular tools and systems that empower a PHP developer. Composer is a Package Manager for 3rd party code and enables it for immediate use into a PHP application. It does this by implementing and adhering to PSR-0 and PSR-4. Confused? let me explain.

Other package managers (or similar style) like NPM, PIP, and Gems tap into a core concept implemented at a languages compile level. When you include an NPM module into your Node application, RequireJS is already hotwired to find and include the request module. Python has a “import” directive and considers packages as modules. Gems are installed on a system level and Ruby makes quick work of including them in your program with a “require” directive. PHP, has no such thing, it’s not tied into a package manager, it’s not designed to look for anything specific outside of the script’s execution itself. If you want to include things, you use a function like “require_once()” and point it to a php script that exists either absolutely or relatively to the script that’s calling it. Another supplemented option provided officially by the language itself, is an autoloader, though it has some limitations. By itself, it’s triggered only when a call to a Class is called that doesn't quite exist yet in the execution stack. PHP will then halt execution to go find the file with the same name as the class from a directory that you specify, and if it cant find it, then throws an Exception. PSR-0 and PSR-4 are proposed clever ways of exploiting the Autoload feature built in, to do some better checking in an infinitely organic folder structure beyond the intended flat single folder architecture, by using a PHP5 feature called ‘Namespaces’. Composer implements this feature.

Basically, when Composer (a cli tool) is invoked within a folder in your application (typically root of the application), its last step is to generate a single file called “autoload.php” based on the results. This single files opens up an infinite world of possibilities within your application. It is a tricked out PSR-0 and PSR-4 autoloader that has your whole vendor folder mapped out, and optionally can even have YOUR application mapped out too in the exact same way so long as it’s told about it. But that’s another topic for another blog.

I guess what I’m trying to arrive at is: the era of messy, dirty, terrible, gross, unmaintainable spaghetti is yesteryears PHP, thanks to the herculean efforts of a new age community spearheading a call to action to bring well designed, maintainable, straightforward, and self-documented PHP to the masses in an as easy to use method as possible to the average joe schmo web dev.

And with that, I bid you adieu until the next blog where we can dive into this stuff a little further.

Thank you for reading this pictureless blog.

I’m always interested in reading your thoughts on the matter. I’m not here to start a flame war on which language is better or which system is stronger or weaker. I’m here to try and start a dialogue that can help the pre-conceived notion that PHP is a terrible language, to people who either haven’t written in it in many years (since the dark ages of PHP5.2 and lower) or who have been told as such by a passionate community supporting a different language for the same purposes and have dismissed it entirely.