On his site today Matin Hujer has posted a tutorial covering the use of the Consistence library, a package that is designed to provide a consistent interface to PHP's functionality.

There is no argument, that PHP can sometimes be a bit inconsistent about naming stuff and maintaining order of parameters for related functions. Also, in some cases it is not strict and allows you to use the language and the functions in a wrong way. Sometimes you get false as a return value where an exception would be appropriate.

[...] Consistence provides opinionated strict wrappers with better error handling and consistent naming and consistent parameters order.

The remainder of the post goes through some of the functionality the package provides including:

• Enums for better type safety
• [Using] ObjectPrototype to disable magic methods
• Consistent array manipulation functions
• [Working with] Regular expressions

As a related piece he's also created PHPStan static analysis rules for the library to ensure it's being used correctly.

On the Stitcher.io blog they've shared a post that makes some suggestions about where a curly brace belongs and how that might differ from situation to situation.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

[...] I wrote about visual code improvements a while back in a previous blogpost about cognitive load. Today I want to focus on that one little, yet very important character in our codebase: the curly bracket. More specifically, we're only going to look at the opening curly bracket, because there's little to no discussion about the closing one.

The post goes on to show several different example situations and where they think the "most correct" placement for the curly brace is. They alos talk about the difference between their use on constructors versus control structures. The main recommendation, however, is to keep things consistent across the codebase.

Christian Mackeprang has a post to his site with some ideas about reducing the "cognitive load" of your code - basically making it easier to follow, read and understand.

Low bug count, good performance, easy modification. Good code is high-impact, and is perhaps the main reason behind the existence of the proverbial 10x developer. And yet, despite it’s importance, it eludes new developers. Literature on the subject usually amounts to disconnected collections of tips. How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!

I believe it’s possible to construct a simple mental framework that can be used with any language or library and which will lead to good quality code by default. There are five main concepts I will talk about here. Keep them in mind and writing good code should be a breeze.

His tips center around concepts like:

• following coding standards for consistency
• clarification through modularization
• overall readability and application structure
• good naming on variables and methods/functions

For each topic he gives a brief summary and some example code, usually showing what not to do and a solution or two to help with the clarification.

In this post on Medium.com Gediminas Rapolavicius provides a word of warning to those creating APIs (interfaces for tools, not like REST APIs) - "don't try to be too smart", favor consistency over cleverness.

When designing an API, it’s tempting to do a bit of extra work and surprise the developers using it. It might be returning some additional information that would require an additional call otherwise, or try to predict the intentions and handle some specific cases differently. The intentions are perfectly fine?—?provide a pleasant, simple interface.

The problem is that it requires making assumptions which, sometimes, are inevitably wrong. The worst case is when the API makes an assumption of what the developer expect to get back, gets it wrong, and returns something unexpected. More work with docs, more bug fixing.

He gives two examples of things he's encountered where the idea of the API was simple but assumptions made turned out to make things a bit more difficult: PHP's own array_rand function and WordPress' update_post_meta. He briefly covers each and explains that, while the intentions seemed good, the implementation was a bit confusing (and at times inconsistent), causing troubles when not functioning as expected.

Davey Shafik has a post to his site with some of his thoughts about the "visibility debate" - essentially when the different method/property visibility types make the most sense.

A lot has been said about when to use public/private/protected. Some say that you should never use private, while others say you should never use protected.

About the only thing that people can seem to agree on is that public should be used with caution. That your versioning should be based around your public API, and you have a responsibility to maintain that API. The issue is mainly around the maintenance responsibility of protected vs private. Given that other developers can depend upon protected, it can effectively be considered to have the same overhead as your public API.

He shares some of his own reasoning behind how he uses the different levels in his own code. He touches on each of the different levels, sharing when and how he thinks it should be used to keep a well-structured, consistent API for your library or application.

On the Digital Ocean blog there's a new post with a "practical overview" of how to effectively scale PHP applications, specifically as it relates to horizontal scaling not vertical.

Shipping a website or application to production has its own challenges, but when it gets the right traction, it’s a great accomplishment. It always feels good to see the visitor numbers going up, doesn’t it? Except, of course, when your traffic increases so much that it crashes your little LAMP stack. [...] But fear not! There are ways to make your PHP application much more reliable and consistent. If the term scalability crossed your mind, you've got the right idea.

The article starts with a brief overview of what scalability is and the main difference between horizontal and vertical scaling (scaling out vs scaling up). They then get into a bit more detail about what horizontal scaling is and how it commonly works in relation to the average PHP application (complete with diagrams). They also talk about some things you can do inside your code to help make things flow a bit more smoothly including decoupling between services and user session/file consistency measures. There's also a bit at the end about load balancing but as that depends a good bit on what technology you're using and the actual load, they just provide an overview and some links to other articles and tutorials with more information.

In this latest post to his site Freek Lijten talks about "the itch" of having or working on something outside the normal project standards.

I assume everybody has certain rules, regulations, guidelines or conventions at their jobs/open source projects. I like structure and consistency so, as long as they are sensible, these things make me happy. Still, every once in a while, something itches. What wins, itch or convention?

He gives an example from some of his current work with an "itch" around using only a call to a registry to save information where business logic isn't needed. He recommends not scratching the itch though, as consistency should win out over other solutions. As he points out, "one day, you will have the need for business logic" and you want to have that structure there to fit it into.

On Reddit.com there's a heated discussion going on in response to this bug filed asking about aliasing PHP function names to make them more consistent (specifically "htmlentities_decode" versus "html_entity_decode").

[...] Current naming conventions are really horrible. For instance, look at differences between str_replace, strlen, parse_str, htmlspecialchars. All work with same type but their names are completely different. So, string functions should go to String namespace (Stringreplace()), array functions to Array namespace (Arraysearch()) and so on.

Back in the Reddit post most of the commentors agree that this kind of thing would be beneficial to the language, but - as several point out - this could have serious backwards compatibility issues. What do you think? Voice your opinion!

On the SitePoint PHP blog today, Kevin Yank shares his thoughts in the form of a list for what makes for "good" and "bad" PHP code.

When interviewing a PHP developer candidate for a job at SitePoint, there is one question that I almost always ask, because their answer tells me so much about the kind of programmer they are. Here's the question: "In your mind, what are the differences between good PHP code and bad PHP code?"

Among the items on the list for the good side are things like: structure, consistency, security, and portability. He gives a bit of example code that shows the three levels of "goodness" in a script (using $_GET variables).

On the SitePoint PHP blog today, Kevin Yank shares his thoughts in the form of a list for what makes for "good" and "bad" PHP code.

When interviewing a PHP developer candidate for a job at SitePoint, there is one question that I almost always ask, because their answer tells me so much about the kind of programmer they are. Here's the question: "In your mind, what are the differences between good PHP code and bad PHP code?"

Among the items on the list for the good side are things like: structure, consistency, security, and portability. He gives a bit of example code that shows the three levels of "goodness" in a script (using $_GET variables).