On his site Brendt has shared some of his thoughts about why he sees the service locator design pattern as an anti-pattern and harmful to your overall application.

As a Laravel developer, I'm confronted daily with the service locator pattern. Every facade call and several helper functions are built upon it.

[...] During a discussion with my colleagues, I found it difficult to put into words what exactly is wrong with grabbing things out of the container - a service locator - so I decided to write my thoughts down, with an example. [...] I want to highlight three problems with this approach, directly caused by the use of a service locator.

He goes through a list of where he sees the use of the service locator functionality causing problems including:

• getting runtime instead of compile-time errors
• obfuscation of actual functionality
• increased cognitive load

He ends the post with a quick suggestion on how to solve the issue: use actual dependency injection instead of "magic" locators.

In his latest post Tomas Votruba shares some of his thoughts around the importance of code readability and the idea of "cognitive complexity".

Cyclomatic complexity is a static analysis measure of how difficult is code to test. Cognitive complexity tells us, how difficult code is to understand by a reader.

Today, we'll see why is the later better and how to check it in your code with a Sniff.

He references this post and this PDF as sources for more information about cognitive complexity but opts for code examples to explain some of the basic concepts. He then gets into the automation of these kinds of checks, using a custom code sniff to check the complexity of the code. He walks through the installation process of the CognitiveComplexitySniff and shares some example results from its evaluation.

On the Stitcher.io blog there's a new article posted about a programmer's cognitive load and offers some tips to help reduce it, especially when reading code that's new to you.

Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

[...] Today I want to share some techniques that can help you reduce this cognitive load while coding. In contrast to some recent advocates of "visual debt", I won't talk about stripping away pieces of your codebase. We'll look purely into the visual aspect: what makes code hard to read and reason about, and how to make it easier.

The tips they article make use of some of the most common features of IDE including adjusting fonts and spacing, using code folding to reduce visual noise and effective naming. Each point has either screenshots or code examples to help illustrate the point.

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.