On his blog Marc Baker about static calls and the trouble they bring in your applications. It's a continuation of ideas that Kore Nordmann shared previously on his site.

It’s been seven years since Kore Nordmann first published “static considered harmful” on his blog, explaining the problems with using static method calls in classes, and the difficulties that they cause when trying to test that class. Seven years on, and those difficulties are still the same, and there is still new code being written using static calls despite that knowledge; but it’s often a more severe problem in legacy code with little or no unit tests.a

So why exactly are static calls so bad? If you’ve read Kore’s article, then you probably have a good idea already; but what that article doesn’t cover is approaches that we can use to make the code testable.

He covers the main issue static methods have when it comes to testing: they introduce coupling by hard-coding a dependency into your code. He talks about the static testing functionality that various PHP testing tools provided: PHPUnit, Phake and Mockery. He then focuses on a newer tool that he's discovered to help make the testing simpler: AspectMock. He gives an example of it in use and some examples of tests using anonymous classes to make it easier to create tests on the fly.

The SitePoint PHP blog has a post about a feature Composer provides to help make tools and libraries easier to use - the ability to install things globally. In this post editor Bruno Skvorc wonders if this feature should be "considered harmful" and a bad practice.

We’ve discussed Composer best practices before, and I’ve always advocated using composer global require when installing packages that can be used across several projects – particularly command line tools. Then, the other day, I ran into this discussion. The short of it is – the majority of people now seem to feel like global require is bad practice, unless the globally installed package has zero dependencies.

The article he references offers an alternative option however: install locally to the project and just update your paths to allow for it to be easily found. This can be difficult and hard to maintain so Bruno offers a counter-suggestion, the "[consolidation/cgr]"(https://github.com/consolidation-org/cgr) tool. This tool handles the "global" install in a way that still isolates it and then automatically updates your .bash_aliases with the command and path to make it easier to use.

In his post over on thePHP.cc site Stefan Priebsch talks about hackathons and why they should possibly be considered harmful. Here he's talking about the ones where a project is given at the start and a product is expected at the end, not just general time for developers to hack together on their own projects.

Last month, at a conference in Bulgaria, I participated in a hackathon for the very first time. The task was to build a small REST API for the tracking of shipping containers and a frontend to visualize a container's GPS position. I would like to share some of my thoughts and experiences (and this is neither going to be about the code we wrote, nor about the fact that we won).

He talks about the team that he was a part of and the different pieces they each contributed. He notes one unfortunate thing though: due to time constraints (3 hours), ramp up time and planning of the application, corners had to be cut to make the deadline.

Going back to the hotel, I realized that during the hackathon, the tight schedule had forced us to do pretty much everything that we all know you should not do. And that we had just experienced a "real" project situation: a tight deadline, not enough communication "because we have no time", rushed technical decisions like just using HTTP "because we have no time", doing things quick and dirty "because we have no time". Does that sound familiar to anybody? Exactly: most teams that I have met (and I have met many of them) experience just this on a day to day basis. And it is wrong.

He suggests that hackathons, in this particular format, should be considered harmful as they reinforce bad decision making and poor development practices. He offers some suggestions that could help to make future events better and an offer to provide guidance for those wanting to make a better event.

In this new post to the QaFoo blog they talk about a common pattern in framework development - the injection of a dependency injection container - and, more specifically, the ContainerAware interface in the Symfony2 framework and why it's "considered harmful".

The ContainerAware interface (actually ContainerAwareInterface, ContainerAware is a basic implementation of it) is part of the Symfony2 API, but a similar concept is known from many other frameworks and many applications rely on it. It defines only the one method setContainer(), which allows to inject the DIC into into an object so that it can directly retrieve services from it. [...Issues with it include the fact that] accessing the DIC in your classes can seriously harm maintainability and code re-usability in the long run.

They talk about three things specifically that using this sort of development pattern can cause in your application:

• Reduced testability
• Hidden dependencies (harder to see when a class has too many)
• Feature sneak-in (that could promote bad usage practices)

There's been a few articles posted on various blogs in the PHP community recently about the "most correct" usage of the "private" scope in your PHP applications. As with any feature of just about any language out there, there's people on both sides of the fence. Here's the ones that have weighed in so far:

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

In this new post to his blog Larry Garfield tries to dispel a common misconception in the PHP development world - that the readfile function should be considered harmful and can cause memory issues in your code.

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

Timothy Boronczyk has a new post to his blog proposing something that any veteran developer already knows - "spaghetti code" is harmful to the health of your application. He's done a little research, though, and tried to explore what this "bad code" really is.

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.

While it's not PHP specific, this recent article from Nat Pryce talks about dependency injection and how the pattern could be considered harmful in the wrong (framework's) hands.

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.

On DZone.com today Giorgio Sironi warns against something that you might not have considered before but could still be harmful to you and your code - meaningless docblock content that could be confusing.

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.

In reference to some comments made on the previous post ("Comments Considered Harmful") to the PHP in Action blog, there's a new post explaining and responding to some of the things said by visitors.

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.