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

Christian Mackeprang:
Writing good code: how to reduce the cognitive load of your code
Jun 22, 2016 @ 11:19:36

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.

tagged: cognitive load understand readability consistency modularization

Link: http://chrismm.com/blog/how-to-reduce-the-cognitive-load-of-your-code/

Medium.com:
Don’t try to be too smart. Be boring, predictable and consistent.
May 11, 2016 @ 12:06:45

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.

tagged: api design boring smart consistency predictable arrayrand updatepostmeta

Link: https://medium.com/@GedRap/dont-try-to-be-too-smart-be-boring-predictable-and-consistent-d63ff2a8e5d1#.ihdjg6j99

Davey Shafik:
The Visibility Debate
Feb 16, 2016 @ 10:43:04

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.

tagged: visibility opinion public private protected api structure consistency

Link: https://daveyshafik.com/archives/69929-the-visibility-debate.html

DigitalOcean Community Blog:
Horizontally Scaling PHP Applications: A Practical Overview
Apr 24, 2015 @ 13:06:49

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.

tagged: scaling application horizontal vertical decouple consistency loadbalance

Link: https://www.digitalocean.com/company/blog/horizontally-scaling-php-applications/

Freek Lijten:
Consistency vs. "The itch"
Feb 20, 2014 @ 09:11:31

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.

tagged: consistency programming development methodology itch

Link: http://www.freeklijten.nl/home/2014/02/18/Consistency-vs.-The-itch

Reddit.com:
Let's Make PHP's Function Names Consistent!
Jan 25, 2013 @ 10:32:57

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!

tagged: function naming consistency language opinion

Link:

SitePoint PHP Blog:
Good and Bad PHP Code
May 28, 2007 @ 09:02:00

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).

tagged: good bad example list structure consistency portability security good bad example list structure consistency portability security

Link:

SitePoint PHP Blog:
Good and Bad PHP Code
May 28, 2007 @ 09:02:00

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).

tagged: good bad example list structure consistency portability security good bad example list structure consistency portability security

Link: