Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

• Test Coverage
• Domain-driven design
• Frameworks
• Event sourcing + CQRS
• Pair programming
• Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

In this new post to his site David Négrier talks about "type hinting all the things" in response to a recent controversy around "clean code" and "visual debt" in PHP code.

Recently, a video about "visual debt" as sparked a lot of controversy in the PHP world. In this article, I'll present the best practices we are using at TheCodingMachine, and a brand new tool we use to enforce those best practices.

If you haven’t seen the video yet, you can have a look at it on Laracast. At some point, the video advocates to remove the type-hints because they are not needed by the program and are "visually polluting" the code.

He then breaks down his look at type hinting and the benefits they can provide into a few sections:

• Type-hints are good
• Type-hints have improved (… but there is still a long road to go)
• Enforcing type-hints

He also covers some of their own best practices when it comes to type hinting in their code and shares a phpstan package that they use to enforce typing and formatting based on their own standards.

Fabien Potencier (creator of the Symfony framework) has a new post on his site continuing his look at Symfony 4. In this latest article he looks at some of the best practices to use in the next major release of the framework based on some of the architectural changes coming down the line.

Any major version of a project is an opportunity to revisit its best practices. Modernizing them. Adapting them to the project's new features. Symfony 4 is no exception.

He breaks it up into a few different sections offering tips around each, just to get you thinking about the path ahead with v4 releases:

• Standardization first (using more standard tools)
• Bundle-less Applications
• Environment Variables
• Unified Web Front Controller
• Makefile
• Assets Management

Each item includes a description of some of the changes coming and what behaviors you'll need to modify to make life smoother in the Symfony 4 transition.

Russell Walker has a post to his site sharing his thoughts defending dependency injection, type hinting and unit testing against some of the common objections.

I've recently been in discussion with a colleague who thinks that dependency injection (DI) is over-used and, in cases where the dependency is a concrete class, unnecessary (in the latter case, he advocates simply creating new objects on the fly).

[...] In my opinion, this line of thinking is misguided, but he sent through some links to pages that he felt supported his point of view (including Tony Marston's rant on DI, and the Laravel documentation about 'facades' - which are actually used as an alternative syntax for the service locator [anti-]pattern). I genuinely wanted to understand the reasoning behind his point of view, as it flies in the face of just about everything I have ever read regarding best practice in PHP development. After reading those resources he sent though, I began to notice some misconceptions about what unit testing actually is, as well as confusion about the difference between code that is "strongly typed" (usually good) and "tightly coupled" (usually bad), and also a tendency to blame the wrong thing when problems arise.

He then breaks the rest of the post down into a few of the common objections and makes an attempt to set the record straight:

• Not All Automated Tests Are Unit Tests
• Using Mocks to Test in Isolation
• What, Never Ever Create Objects on the Fly?
• What About Those Laravel Facades?
• Hidden Dependencies and Other Dangers
• Strongly Typed is not Tightly Coupled

He ends the post with "another reason" that there could be issues with developers dismissing best practices in their development - a misunderstanding of the principle and how to correctly implement it.

Stefan Koopmanschap has a new post to his site sharing some best practices with bundles in Symfony including structure of both the bundle and the application it lives in.

On one of my recent commutes I started listening to the Sound of Symfony podcast. As I had just discovered that one, I decided to listen to their most recent episode, which is on best practices for bundles. I quite disagreed with what was being said in the podcast. I started voicing my disagreement on Twitter but quickly decided that 140 characters is not enough to really explain my disagreement. So here's a blogpost.

He starts by talking about some of the current "best practices" documentation (like this book) and the parts of it he disagrees with. He talks about the use of the AppBundle, the general structure of a Symfony project and the use of bundles to provide better structure to your own code. He covers the placement of you code (your "domain") and the integration of the idea of bounded contexts. He finishes the post with some of his own experience with various frameworks and both good and bad project structures - and how sometimes the default framework structure isn't really what's needed.

On the Exakat blog there's a new post sharing six good practices for "use" in PHP. The "use" keyword has a few different places it is used in PHP (like importing namespaced classes and passing in values to closures).

While reviewing code recently, I realized there are no guidelines for use. Every modern code do use ‘use’ (sic), as importing classes from composer or a framework is the norm. There are now quite a few variations in syntax for importing classes or traits. Although the impact on performance is low, as use is solved out, having a clean approach to ‘use’ is important to keep the code clean and readable. Let’s review what are the six good usage of use.

Each of the six tips they share come with a bit of explanation and code to back them up:

• Do not import unused classes
• Alway use alias
• Place all use at first
• Avoid using the same alias for different classes
• Group use expression for easy reading
• Limit the number of use expression

Some of them could be argued as to whether or not they're a "best practice" but it'd definitely interesting to see some tips for the use of this increasingly common little keyword.

On the TutsPlus.com site there's a tutorial posted about using PHP CodeSniffer with WordPress, a popular PHP coding standards tool that helps enforce common coding practices and style in your application.

Oftentimes, the way in which we write code depends on how we got started with programming. [...] In this article, we're going to take an introductory look at code smells. We're going to examine what they are, what they look like, and how they often manifest themselves in the work we do. We'll be using PHP for our examples.

They start with an introduction to the topic of "code smells" including a few examples along with matching code snippets:

• Example 1: Clear Naming Conventions
• Example 2: Stay DRY
• Example 3: Long Parameter Lists

They also include some solutions that can help you avoid these "smells" in your code and refactor out ones that might already exist.

While not specific to PHP (the examples are in Ruby, in fact) this new tutorial on the Toptal.com blog has some good information and suggestions around the use of exceptions in your applications.

Exceptions require special treatment, and an unhandled exception may cause unexpected behavior. The results are often spectacular.

Over time, these errors, and countless others [...] contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming; they exist to make our software better. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable.

They start by talking about why exception handling is a good thing and some common practices to help make them more manageable. They suggest that good exception handling can also help make your code more maintainable, extensible and readable in the long run. He suggests creating your own kind of exception hierarchy (more possible in PHP 7) and using them to get more specific on the type of exception that was thrown. He recommends not "rescuing" exceptions more than needed (in PHP this is try/catch) and that it's okay to defer the handling for the exception being thrown and not deal with it right away.

He also reminds you that not all exceptions need handling in your own code (sometimes it's up to the user) and that following conventions on naming can help end users better understand why there's an error. Finally, he recommends logging exceptions as they're major errors in your application, not just data problems or smaller bugs.

In this new post to thePHP.cc blog Sebastian Bergmann (creator of the PHPUnit unit testing tool) questions of some the current "best practices" involved in using the tool. More specifically he looks at the handling for expected exceptions and proposes a new practice to use going forward.

It is important to keep in mind that best practices for a tool such as PHPUnit are not set in stone. They rather evolve over time and have to be adapted to changes in PHP, for instance. Recently I was involved in a discussion that questioned the current best practice for testing exceptions. That discussion resulted in changes in PHPUnit 5.2 that I would like to explain in this article.

He talks about the currently widely used practice of the @expectedException annotation to define when an exception should be thrown from the code inside the unit test. Sebastian talks about the evolution of this into other annotations around the code and message returned from the exception too. He then proposes the new best practice as a result of some discussion around the annotation method: returning to the use of the setExpectedException method. He provides some reasoning behind the switch including the timing of the exception being thrown (not just "any time" but a more specific time).

On the PHP.cc's site has an article that looks at dependencies in disguise based on a "workshop" one of their members, Stefan Priebsch, gave at the recent Bulgaria PHP Conference.

Yesterday I gave a presentation at the [Bulgaria PHP Conference](https://thephp.cc/dates/2015/09/bulgaria-php-conference) (a great event, by the way). Following an [ad-hoc workshop](https://twitter.com/s_bergmann/status/647732967087939584) that I gave as part of the hallway track and an entertaining hackathon, I decided it was too late to join the party and went back to the hotel with some other speakers. Checking out how the day was reflected in social media, I contributed a few more tweets to a [conversation](https://twitter.com/tim_bezhashvyly/status/647861115721003008) that had started earlier in the day ([here](https://thephp.cc/dates/2015/09/bulgaria-php-conference/solid-mvc) are the slides of my talk that people are referring to). I am writing this to clarify my point, and help everybody to understand better.

He talks about dependency injection as a best practice that's followed in libraries all over the PHP ecosystem, making it easier to work with objects and their needs. Sometimes this means using a dependency injection container and others it's just constructor/method injection. He talks about how these objects are build in factory methods and recommends making one factory but points out that this only really works when all the objects you need are known up front. However, he gives several (code) examples of places where this could be difficult and how some are using service locators to solve the problem. He points out, however, that this then expands the API of the application out way too far, opening it up to objects all across the application when there may be no need. This is where the hidden dependencies can come in, things masked behind the use of a single service locator. He recommends solving the issue with more customized locators, as in his example of routing locator used to handle dependencies for a POST HTTP request.