Why the PHP Conventions

If you want to understand the reasoning behind the recommended conventions, read on. Otherwise, you can just skip this and follow the conventions


Modern programming languages generally share common notational or semantic constructs. (Wikipedia has interesting articles on the evolution of programming languages.) There is broad practical experience with the items in the style guide. While not the subject of objective testing, experience suggests certain coding styles are better for reading and comprehension.

I’m comfortable with the more dense coding style typically practiced for C. I have long experience coding in Java, C++, C and other languages all the way back to Fortran. But to improve readability, I made minor adjustments to my coding style primarily related to adding more whitespace (spaces and newlines). The ultimate goal of any style guide is for the ability for others to easy grasp your code. So I changed. Not for my benefit but for others that might read my code.

The style guides in PSR-1 and PSR-2 are purely subjective but helpful in getting a team to all use the same coding style. And once set up, some developer tools will even coach you to follow the style guides.


WordPress was created when PHP was a purely procedural language. So most of its actual conventions relate to doing procedural programming. I feel there are advantages to using PHP’s modern object-oriented language extensions. These extensions are mainly useful in regards to name scoping and conflicts. A name conflict happens when the same name is used to refer to different things. These can be different functions, variables or constants. This conflict usually happens because the different developers (such as for different plugins) don’t know of each other.

There is theoretical debate on the merits of object-oriented programming as opposed to functional programming (see Object-Oriented Criticism). Object-oriented (or OO) thinking is just a tool. Sometimes appropriate; sometimes not. And any tool can be misused. I find OO thinking helps me when I return to a piece of code after a period of time. It also helps force a separation of concerns architecture.

Before modern PHP that introduced namespaces, each developer was responsible for picking their own unique names. The convention developed of adding a few characters followed by a ‘_’ to the front of each name to make names unique. And the PHP Extension and Application Repository (PEAR) system took advantage of that convention to manage packages–collection of related code.

Modern PHP introduced namespace and use statements that changed the way unique names are formed. Subdequently the use of PEAR has given way to using a more modern tool Composer.

WordPress core code adopted the convention of prepending the word “class-”  to the file name.



Something akin to the recommended conventions has been used by many for many years. For example, WordPress 3 is very different from WordPress 4 which is very different from WordPress 5. But to create an automatic tool, you need the precision of a formal specification and not rely on human interpretation. The convention provides the necessary precision while still allowing some flexibility.


Every large system has to solve the problem of automatic loading of code. Manual procedures don’t scale well and are very error-prone. Drawing inspiration from other language tools, Composer is a tool for dependency management that will also create efficient autoloaders.