In a new post to his site Leonid Mamchenkov talks about complex arrays in PHP and links to two articles offering different opinions on their use.

Now that PHP 7+ sorted out a whole bunch of problems with type-hinting of parameters, return values, variables and properties, we turn our attention to somewhat deeper issues.

Array is a native citizen in PHP. Arrays are very convenient and are widely used. However, if you stop and think about the times where you had to figure out somebody else’s code, I’m pretty sure complex arrays will come to mind at some point.

The first article takes the positive approach, showing you how to create better handling for complex arrays in your applications. The second takes the opposite approach, showing how to avoid complex data structures in your code, opting for classes and objects instead. He notes that he thinks both articles have their good and bad points and references another blog post of his that provides yet another way to solve the need for complex data structures.

In a new post to his site Tomas Votruba takes the opposite approach to writing good code by sharing bad examples in the form of fourteen tips to write bad code, practices that can make code hard to upgrade and difficult to maintain.

Today I'll show you how to own your company. All you need to do is write code that no-one can read, is hard to refactor and creates technical debt. It's not easy, because if other programmers spot you're writing legacy code, you're busted.

If you keep a low profile of very smart architect and do it right, you'll be the only one in the company who knows what is going on and you'll have a value of gold. Learn how to be successful living vendor lock!

He then goes through his list of poor practices to avoid including:

• Use protected instead of private
• Use Non-String Method Names
• Don't Always use PSR-4
• Hide Your Dependencies in Constructor
• Use Annotations to Define Magic Methods
• Use Traits with Annotations to Define Magic Methods
• Use as Short Naming as Possible

...and many more. For each item in the list sample code is provided so you'll know exactly what to avoid.

On the php[architect] site they've shared the contents of one of their regularly published columns - "The Dev Lead Trenches", written by Chris Tankersley - covering burnout of developers from their day-in and day-out work.

The tech industry is a double-edged sword. On the one side, we (generally) have well-paying jobs with nice perks, but on the other, we can easily slip into not only boring, repetitive work but figurative death marches. The former is used by most companies as an offset to the latter, but that rarely works out well. This leads many developers to come face-to-face with burnout.

He starts with some suggestions of ways to detect burnout in your own life including lack of motivation, sleep, and other emotional types of signs. He then makes a list of suggestions of how you can avoid burnout in your own work:

• set working hours
• use vacation time
• take 15 minute breaks
• take up hobbies outside of development

There's several others in the list too, so I'd recommend checking out the full article for more information about each.

Brandon Savage has a tutorial posted to his site covering the use of setter injection, some of the issues that can come with using it and how to avoid it.

PHP more or less has two kinds of dependency injection available: constructor injection, and setter injection. Constructor injection is the process of injecting dependencies through the constructor arguments. The dependencies are injected via the constructor, on object creation, and the object has them from the very beginning.

Setter injection is different; instead of providing the dependencies at construction time, the dependencies are provided via setter methods, once the object has been constructed. This allows the flexibility to configure the object during the runtime, rather than at construction.

He goes on to point out two flaws with setter injection: "half-baked" objects and the injection of potentially unused objects/resources. He spends the remainder of the post covering each of these topics more specifically and wraps it up with a recommendation to avoid it if possible and opt for useful, "fully baked" objects injected via the constructor instead.

The Pehapkari.cz blog has posted the latest article in their "Domain-Driven Design" series of posts covering the focus on the "domain" when developing an application rather than just features. In this latest tutorial, they cover services and factories to help with the encapsulation of functionality...and why they shouldn't be used.

This article is a reaction to readers’ confusion about services. We'll cover a domain service and domain factory in this article and when to use them and when not to.

Domain-driven design is about the domain. Domain services and domain factories do not exist in the domain. In general, we shouldn't use them. They are artificial constructions and this causes a lot of problems with code understanding, maintainability and also a divergence between the domain, the model, and the code.

The article continues the use of the e-commerce example when talking about the ideas of services and factories in the domain. It provides some basic examples (flow diagrams included) and the reasoning why they should not be used and what they could be replaced with.

In this new post on thePHP.cc site they talk about calling instance methods statically, more specifically that it should be avoided.

There are quite a few things in PHP 4 that were a bit strange. One example is that PHP 4 allowed static calling of instance methods. [...] To keep backwards compatibility with PHP 4, this code works up to PHP 5, even though [the method in the example[ is not declared static.

[...] Now things will get really weird. When calling an instance method of another class statically, the $this context would carry over from the caller to the called class. In other words, $this suddenly refers to another object instance. While in PHP 5, this used to be an E_STRICT error, PHP 7 will emit an E_DEPRECATED error.

They point out that, while this is definitely odd behavior that shouldn't exist, it hasn't been removed because of PHP's backwards compatibility principles and only removing functionality like this in major versions. So, instead, they recommend calling all non-static methods using an instance of the class injected rather than directly calling them.

On the DaedTech blog Erik Dietrich has written up a list of a few things he suggests avoiding when using logging functionality in your application. The suggestions range from the actual contents of the message out to some logging best practices.

It seems almost strange to talk about avoiding things while logging. After all, logging is your last line of defense or your salvation in many cases. [...] Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems. You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it. You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them? Let’s take a look at some things that can come back to bite you.

He points out the following (common) bad practices he has seen during his time developing:

• Forgetting Context
• Cryptic Codes
• Spamming the Log File
• Unsafe Logging Calls
• Mixing Application Logic with Logging

He ends the post with a suggestion of "sensible logging" - capturing as much meaningful information as possible while not overdoing it. Logs can be a powerful ally when hunting down an issue or trying to provide documentation of a security issue. Log wisely, log on purpose.

Phil Sturgeon has a post to his site with a good recommendation for those working with APIs and those "magic numbers" that are HTTP status codes - avoid hard coding them in your applications and tests.

A lot of things in programming are argued to death, but one subject where people almost unanimously agree is that magic numbers can be a pain in the ass, and they should be avoided whenever possible. Sadly when it comes to HTTP status codes, people keep on hardcoding them, and it leads to all sorts of confusion. [...] What is 409? If you answer without looking it up on Dash or HTTP Status Dogs then you are a machine.

He shows two implementations of this idea, one in Ruby and the other in Symfony, where the status code value is represented by a constant rather than by a number. The constant correlates to the HTTP status code (number) but the constant makes it easier to read and understand the code. He points out two libraries that can be substituted into your current testing to replace those hard coded values with more expressive versions: lukasoppermann/http-status and Teapot.

The ByMyCTO.com blog has a recent post that makes the suggestion that the Doctrine ORM isn't suited for PHP...or to put it another way why they think it's not a good option for database integration.

I know, this title sounds like a troll. But it’s not, it’s a fact. I’m not saying Doctrine is a bad technology or shouldn’t be used. I’m just saying it’s not suited for PHP and this can lead to critical problems if misused.

He covers a few different topics including:

• Differences between Java and PHP (and the fact that Doctrine's inspiration was Hibernate)
• The "session problem" (entity serialization)
• Identity Map, useless in a stateless environment
• UnitOfWork, far too complex
• EntityManager, too magical

Despite all of these points, he does remind the reader that Doctrine isn't useless or inherently bad, it's just that he sees it as reinforcing bad behaviors and suggests using something else.

In a recent post to his site Sahand Saba has posted a list of nine anti-patterns every programmer should avoid. This list isn't language specific and ranges in types of advice from general programming practices down to more specific "code smells" to avoid. The code examples are in Python but you can interpolate them into the world of PHP pretty easily.

A healthy dose of self-criticism is fundamental to professional and personal growth. When it comes to programming, this sense of self-criticism requires the ability to detect unproductive or counter-productive patterns in designs, code, processes, and behaviour. This is why a knowledge of anti-patterns is very useful for any programmer. This article is a discussion of anti-patterns that I have found to be recurring, ordered roughly based on how often I have come across them, and how long it took to undo the damage they caused.

The list of nine includes things like:

• Premature Optimization
• God Class
• Inner-platform Effect
• Management by Numbers

Each item on the list includes a few subheadings talking about what it is, why it's bad, how to avoid it and some code examples (where appropriate) to find it in your code.