• Brandon Savage's initial post (an excerpt from his upcoming "Do This, Not That" book)
• A response to this from Anthony Ferrara
• Brandon's own response to comments on his previous article
• This new post from Larry Garfield and some of his experience from the Drupal world

Various topics come up during these posts including static coupling, using interfaces versus inheritance, wrapper classes and developer intent.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

The phrase "spaghetti code" is an all-too-common pejorative we programmers use to describe horrible code, whether it's difficult to understand, poorly organized, or just plain long-winded. And there-in lays the problem. What really constitutes spaghetti code is subjective; I've yet to hear a concrete definition or standard metric that measures it. [...] Everyone has his or her own opinion as to what aspects would make them label it spaghetti.

Suggested definitions include: quickly written, non-standardized, beginner-level quality and any code that makes use of "goto". He suggests that applying the term to someone's code is less about the real quality of the code and more about social aspects of not wanting to upset the other developer over its quality.

But besides negatively affecting others, our complaining about spaghetti code hurts ourselves too. It's easier to motivate ourselves when tasked with fixing a bug when we're not dreading having to trudge through spaghetti. When we label code as spaghetti code, we are actually creating roadblocks that hamper ourselves and artificially increase the difficulty of the task at hand.

There are two aspects to Dependency Injection. Firstly, an object's interface should define the services that the object requires as well as those it provides. Secondly, the code that satisfies the requirements of an object by giving it a reference to the services of is collaborators is external to both the object and its collaborators. [...] The name "Dependency Injection" only relates to the second aspect. And worse, makes it sound like dependencies are "injected" through the object's encapsulation boundary rather than explicitly defined as part of the object's API.

He gives an example from the GOOS project where objects are independent and APIs are defined in such a way that any dependencies are clearly distinguished. "Code that composes objects is separate from the objects being composed".

The end goal is to need less and less code to write more and more functionality as the system grows.

Be sure to check out the comments on the post for some other good opinions and suggestions regarding dependency injection and its use in frameworks.

However, docblocks may become as evil as comments when they're not treated as first-class citizens. [...] Too often docblocks are generated and left there without any additional information. In other cases, they are filled mechanically with information that can already be inferred. In that case, you're not helping the programmers, which will have to maintain that docblock containing information duplicated from the method signature.

He offers a few hints to follow to make sure you stay out of the bad docblock trap - don't repeat the code definition, don't repeat the logic of the method, not using the <code> tag and using @throws correctly.

Conflict is not a bad thing. That is, if it leads eventually towards clarity and understanding rather than confusion and misunderstanding. [...] A debate about a technical matter may be conducted in parallel with an altercation that addresses the relationship between the participants. This is confusing in itself. Keeping these discussion apart will help maintain clarity.

Using this tact, he responds to the criticism made on the previous post, specifically one that points to this article as to why "considered harmful" articles should only be seen as fodder for argument and should be "considered harmful" themselves.

There is too much old advice in PHP. A recent case comes from the PHP Advent calendar. Eli White is a strong believer in commenting code, including inline comments inside functions. Unfortunately, he's at least 10 years too late. This used to be good advice, but not any more. Up to a point, he's right.

They propose a better way - refactoring code so that its as easy to read as possible, reducing the need for extensive commenting. They illustrate with a rework from the Zend Framework function, changing up the method names to better reflect the action inside (rather than the current "doUpdate").

Everybody who writes object-oriented code knows about constructors. You need them so the program knows how to instantiate objects, right? And you especially need them when a lot of things have to be done while instantiating an object. [...] So why would I be skeptical of public constructors?

The solution, as he sees it, is to make a "constructor" that's actually called statically with parameters that returns an instance of the class it's in as well as performing the action. He argues that this can help make the code much more readable for some types of method calls.