Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Leonid Mamchenkov:
Feature Flags in PHP
Dec 20, 2016 @ 09:16:29

In a new post to his site Leonid Mamchenkov talks about feature flags, a handy tool you can use in your application to enable/disable features and or risky changes in your code allowing you more production-level control.

Today edition of the “Four short links” from the O’Reilly Radar, brings a quick overview of the different feature flag implementations. It touches on the following: Command-line flags, with the link to gflags, A/B flags, Dynamic flags [which are more difficult] and more complex systems.

I’ve dealt with feature flags before, but never found an elegant way to scale those. [...] These days, something more robust than that is necessary for some of the projects at work. Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel.

He talks about some of the challenges that he had in his own feature flag implementation including naming of the flags and where the flags should be placed. He then links to the PHP Feature Flags site and various PHP libraries that implement feature flags slightly differently and cover cookie-based, IP-based and URL-based features. He ends the post by pointing out that the lack of feature flags in any complex application is usually considered toxic when it comes to being able to scale an application correctly.

tagged: feature flag example challenge library naming location introduction

Link: http://mamchenkov.net/wordpress/2016/12/20/feature-flags-in-php/

Alain Schlesser:
Structuring PHP Exceptions
Oct 31, 2016 @ 10:46:25

Alain Schlesser has written up a new post for his site sharing some of his suggestions for structuring your PHP exceptions including localization, catching them and using them with named constructors.

I seem to constantly work on improving my habits regarding the use of exceptions. I think it is an area that I haven’t yet fully explored, and it is very difficult to find anything more than very basic explanations and tutorials online. While the consensus is to use exceptions, there is very little information on how to structure and manage them in a larger codebase. The larger and more complex your projects become, the more important it is to start with a proper structure to avoid expensive refactoring later on. Your client will surely be thankful!

In this article, I want to talk about the way I currently set them up and use them in PHP, in the hopes to spark some discussion on the topic and get further feedback.

He starts with a few thoughts about why even using exceptions is a good idea (over just errors) and how to build on the included SPL exception set. He then gets into the suggestions about:

  • naming conventions
  • using named constructors to encapsulate logic
  • working with localized exception messages
  • catching exceptions

He ends the post by suggesting one last piece that can help make catching and handling exceptions easier - a centralized handler, something potentially like BooBoo from The PHP League.

tagged: exception handling tutorial naming namedconstructors localization catching

Link: https://www.alainschlesser.com/structuring-php-exceptions/

SitePoint PHP Blog:
Cleaning up Code: Is Refactoring for Aesthetics worth It?
Jul 18, 2016 @ 10:16:17

On the SitePoint PHP blog Tobias Schlitt has an article posted that tries to answer the question "is refactoring for aesthetics worth it" for most development groups out there.

Most development teams want to get their codebase into a better, more maintainable state. But what definition of better should be chosen? In many cases, it is not necessary to dig deep into Domain Driven Design (DDD) to achieve this goal. Sometimes, it's even counter productive. But one of the most basic collections of principles can help each team a lot already: Clean Code.

The Clean Code book by Robert C. Martin summarizes many simple and advanced improvements to get better, understandable, and therefore more maintainable code.

He goes on with a bit of example code, showing a getJobs method that has room for improvement. He makes recommendations on cleanup steps like: renaming variables for clarity and breaking up code more visibly based on functionality. He then talks about the "methodology of refactoring" and how to take "baby steps" in your updates rather than major jumps. He ends by pointing out that refactoring for "beauty" sake isn't a good idea nor is doing it without a sufficient level of automated testing to ensure changes didn't break the application.

tagged: refactoring aesthetics babysteps opinion example naming cleancode

Link: https://www.sitepoint.com/cleaning-up-code-is-refactoring-for-aesthetics-worth-it/

SitePoint PHP Blog:
How Laravel Facades Work and How to Use Them Elsewhere
Nov 05, 2015 @ 11:55:49

The SitePoint PHP blog has a new tutorial posted showing you how Laravel Facades work and how they ("Facades") can be used in other framework types.

The Facade pattern is a software design pattern which is often used in object oriented programming. A facade is, in fact, a class wrapping a complex library to provide a simpler and more readable interface to it. The Facade pattern can also be used to provide a unified and well-designed API to a group of complex and poorly designed APIs. The Laravel framework has a feature similar to this pattern, also termed Facades. In this tutorial we will learn how to bring Laravel’s "Facades" to other frameworks.

He starts off by looking at how the Laravel framework has implemented facades through out the entire framework. He includes examples of using these facades (like the App to make a new object instance) and how the base Facade class is structured to make it work. He covers some of the basic features of the classes that extend this base and how they're aliased in the Laravel code/configuration. He then gets into using this same sort of "facade" approach to other frameworks, specifically in an app based on the Silex microframework. He lists some of the requirements and shows how to pull in the base Facade class to extend. He also integrates the aliasing code and configuration to make it simpler to use the short names rather than full namespaced versions of the classes.

tagged: laravel facade introduction tutorial silex approach naming

Link: http://www.sitepoint.com/how-laravel-facades-work-and-how-to-use-them-elsewhere/

Paul Jones:
SQL Schema Naming Conventions
Nov 04, 2015 @ 12:15:59

Paul Jones has a post to his site looking at SQL schema naming conventions and some of his own thoughts on the matter. There's a lot of different camps of thought around naming, much less database ones, and he makes a few suggestions learned from his experience over time.

Several weeks ago I asked on Twitter for SQL schema naming conventions from DBA professionals. (I’m always interested in the generally-accepted practices of related professions; when I can, I try to make my work as compatible with theirs as possible.)

I got back only a handful of responses, representing MySQL, PostgreSQL, and DB2 administrators, really not enough for a statistically useful sample. Even so, I’m going to present their anonymized responses here, because they led me to work I had not previously considered at length.

He asked about things like singular vs plural names, primary key choices and naming of association tables. The uses the rest of the post sharing the responses he got from his questions with a good range of responses representing both sides of each question. He wraps up the post looking at what these answers mean to the average developer and the answers that Joe Celko and Simon Holywell have to say on the matter.

tagged: sql schema naming convention feedback table primarykey association feedback

Link: http://paul-m-jones.com/archives/6188

Dylan Bridgman:
Writing highly readable code
Jul 30, 2015 @ 12:29:55

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

  • the overall style of the code
  • the structure of the application (directories, libraries used, etc)
  • naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

tagged: write readable code tips style structure naming convention comments

Link: https://medium.com/@dylanbr/writing-highly-readable-code-94da94d5d636

Phil Sturgeon:
A Quick Note on PSR Numbering
May 06, 2015 @ 09:41:55

With a lot of talk happening around the PSR-7 HTTP request/response proposal and PSR-4 being the last "official" standard to be posted, some people are wondering what happened to PSR-5 and 6. Phil Sturgeon, a previous member of the PHP-FIG, has posted some clarification to how the PSR process works and where those seemingly missing PSR numbers are at.

The last PSR from the FIG to be sent out into the world, to be used by whoever felt like using it, was PSR-4: Autoloader. Now people are starting to hear about PSR-7, and they’re starting to “lolphp”, wondering what has happened to PSR-5 and PSR-6. [...] This is not like The Neverending Muppet Debate of PHP 6 v PHP 7, despite it being the first though to pop into many peoples heads. Instead, this is down to the Workflow Bylaw I put into place last year.

He goes on to talk about the current workflow stages and how, unlike systems in other languages, the PHP-FIG's process gives proposals a PSR number even before they're published and accepted. He also briefly talks about PSR "nicknames", naming to differentiate between similar proposals and how, despite the need for these names, they're just reference points for conversations more than anything.

tagged: psr7 psr proposal workflow process numbering naming phpfig

Link: https://philsturgeon.uk/php/2015/05/05/psr7-numeric-workflow/

Piotr Pasich:
ClassManager - You shall not pass
Jan 30, 2015 @ 11:42:55

Piotr Pasich has shared some thoughts on naming in his latest post to his site today. In it he talks about one of the "hardest things in computer science" (naming things) and makes some recommendations to help you make naming in your code more effective.

Precise names for classes is notoriously difficult. Done right, it makes code more self-documenting and provides a vocabulary for reasoning about code at a higher level of abstraction. There are a couple simple tips&tricks to make the names more readable: do not abbreviate, do not add any extra informations (underscore, type), avoid single letter prefixes, etc etc.

But what if you already know and use those rules and you still want to improve naming in your code? I assume that you care, you’re not selfish and you think about elses when you write the code. You ask one of the most important question to yourself, during architecture implementation – how the fellow sitting next to will behave while reading the code.

He's broken up the remainder of the post into different sections, each with a high level recommendation and some follow up description:

  • Ask somebody else
  • Does it have a single responsibility you can name?
  • Simple Superclass Name
  • Qualified Subclass Name
  • Adding ‘Interface’ word

He ends with a few names to avoid (like *Manager, *Helper or *Handler) to help prevent ambiguity. He reinforces providing meaning in your naming and making it easier for others to understand what's going on.

tagged: classmanager naming opinion recommendation avoid meaning

Link: http://piotrpasich.com/classmanager-you-shall-not-pass/

Jani Hartikainen:
How to make your code self-documenting?
Dec 02, 2014 @ 09:35:21

In this new post to his site Jani Hartikainen suggests a few things you can do to help make your code "self-documenting" and more readable down the line (or for other developers).

Isn’t it fun to find a comment in code that’s completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand? One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn’t need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it’s less likely they’ll be crap! In this article, I will show you several ways you can make your code document itself.

He breaks it up into a few different sections, each with some code examples and descriptions:

  • Naming things
  • Extract functions
  • Introducing variables
  • Defining class and module interfaces
  • Code grouping

He finishes up with a few smaller tips including "don't use strange tricks" and "use named constants". What do you think makes for good self-documenting code? Share some of your own thoughts on the post.

tagged: selfdocumenting code examples naming separation extract group

Link: http://codeutopia.net/blog/2014/12/01/how-to-make-your-code-self-documenting/

Phil Sturgeon:
The Neverending Muppet Debate of PHP 6 v PHP 7
Jul 24, 2014 @ 10:18:14

Phil Sturgeon has posted about something he calls the "neverending muppet debate of PHP 6 versus PHP 7. As the PHP language moves forward, the PHP 5.x series is coming to a close. The discussion as started up whether to name it "PHP 6" or "PHP 7" and both sides have their proponents.

There are a few major, important conversations happening in the PHP internals mailing list as we speak: The Facebook lot heading up a specification based off of PHP 5.6 Should phpng be moved into master to be the base of the next major PHP version How can we best go about scalar typehinting? There is also another conversation: Should it be PHP 6 or PHP 7 Wait... what?

He goes on to provide a little context, pointing out that back in 2010 PHP 6 was being slated for release as the next major version of the language (this was around the PHP 5.2 days). Unfortunately, it stalled out and some of what was planned went into PHP 5.3. This didn't stop publishers from releasing books and articles about "PHP 6" though. It's already being put up for a vote with "PHP 7" pulling ahead. Phil also includes more context around the discussions, sharing the main points of each side and snippets from the RFC and mailing list thread currently ongoing.

tagged: debate php6 php7 naming internals rfc version

Link: http://philsturgeon.uk/blog/2014/07/neverending-muppet-debate-of-php-6-v-php-7