In a post to his site, Matthias Noback talks about code complexity and how this relates to the overall "churn" (the rate of change) in a project.

Code complexity often gets measured by calculating the Cyclomatic Complexity per unit of code. The number can be calculated by taking all the branches of the code into consideration. [...] In general, we always strive for low code complexity. Unfortunately, many projects that you'll inherit ("legacy projects"), will contain code that has high code complexity, and no tests.

[...] Code complexity doesn't always have to be a big problem. If a class has high code complexity, but you never have to touch it, there's no problem at all. [...] What's really dangerous for a project is when a class with a high code complexity often needs to be modified. Every change will be dangerous. [...] Michael Feathers introduced the word "churn" for change rate of files in a project. Churn gets its own number, just like code complexity.

He then talks about combining these two numbers to provide an even more in-depth look at your code. It can give more insight into the relationship between "difficult to change", "number of changes" and the times a file has changed in the past. He mentions "it's okay" thinking (the current state is alright but not great) and shares some of his own hypotheses, observations and advice.

Derick Rethans has a post to his site covering some optimizations around PHP's "switch" handling and how it has changed in the upcoming PHP 7.2 release.

PHP 7.2 is around the corner soon, and comes with many optimisations. Many new optimisations are implemented in opcache, but some others are implemented in PHP itself. One optimisation that falls in the latter category is an optimisation of the switch/case construct.

He then gets into the differences between the previous functionality and how it has changed, mostly in how the language handles the evaluation of the "case" statements. He include a flow diagram of how the pre-7.2 flow happened and how, with PHP 7.2, a "jump table" is used to optimize the process. This table allows PHP to perform a lookup on the value rather than evaluating equality (like in an if) on string values. If it's not a string the same evaluation happens as before, however.

In this post on Medium.com Ond?ej Mirtes introduces a tool that can be use to statically analyze your PHP application and locate bugs without the need for tests - PHPStan.

Keeping up with modern PHP practices leads to codebases where we can be sure about types of a lot of data, converging with statically typed languages, although the dynamic nature is still present. Modern PHP codebases are similar to the ones in languages people make much less fun of. Object-oriented code, dependency injection and usage of established design patterns are truly common nowadays.

Which led me to the idea of a static analysis tool for PHP that would substitute the role of the compiler from other languages. I’ve spent a lot of time working on it and I’ve been employing its various development versions checking our codebase for more than a year.

It’s called PHPStan, it’s open-source and free to use.

The post goes on to talk about some of the checks that PHPStan performs (with more information available in the project's README). He also talks about the performance of the tool, how to extend it and configuring it for "strictness". He ends the post by pointing out that, despite the title of the article, he still encourages writing tests, just making sure they're "meaningful ones" that test more than just syntax.

The SitePoint PHP blog has posted a new tutorial from author Christopher Pitt on an interesting topic that could come in very handy in the right situations: finding differences in images with PHP.

I recently stumbled across a fascinating question: how could I tell whether an image had changed significantly? As PHP developers, the most troublesome image problem we have to deal with is how to resize an upload with an acceptable loss of quality. In the end I discovered what many before me have – that this problem becomes relatively simple given the application of some fundamental mathematical principles.

He starts off by talking about images as "bitmaps", basically a collection of pixels composed in a grid. He also mentions images as sets of vectors, but in PHP the bitmap approach is simpler and more understandable. He includes some code showing the breakdown of an image into its RBG colors values and what the data represents. He then moves into measuring the distance "in three dimensions" with a bit of geometry and applies them to a simple State class. This class breaks down the image given into RBG details then, eventually, compares the other image based on the euclidean distance between the points on the original and the ones from the new image. He filters some of these results through a standard deviation view to weed out problems with almost identical images.

Matt Stauffer has a post to his site showing you how to use custom conditionals with Blade, the templating engine for the popular Laravel framework.

One of the greatest aspects of Laravel Blade is that it's incredibly easy to handle view partials and control logic. I find myself frequently extracting the contents of a loop out to a Blade partial and then passing just a bit of data into the partial.

But sometimes the repetitive code isn't the view itself, but the conditional logic I'm running.

He gives a practical example of an issue he had in some recent work he's done: a simple site for his physical trainer that needed to test for public vs non-public resources. The same evaluation code was being pasted all over the site so he looked for a better way. He introduces the idea of a custom directive in Blade and how they're converted to PHP out in the view. He shows how to make an @public directive to replace his cut-and-paste logic from before and make the template much cleaner. He includes the code for this simple directive and ends the post with some other possible options use could use the directives for.

Rob Allen has a post to his site to help clear up some confusion with how the ZendInput component handles "empty" between the required, allow_empty and continue_if_empty logic.

These settings define what happens when you try to validate an empty value for a given input. For ZendInput, empty means exactly equal to null, an empty string or an empty array.

He starts by outlining each of the three settings including both their default settings and its intent. He gets into a bit more detail on continue_if_empty as it has additional logic that depends on the results of the other two settings. He includes a small test application that cycles through a set of values and evaluates them through a ZendInput instance. The output is also included in the post so you can verify your system is seeing the same evaluation results.

If you've ever worked with the "cron" tool on a unix-based system, you know that there's a special syntax that comes along with defining when the commands should run. It can be difficult to get this timing exactly right, especially if you're very picky about the execution time. In this post from Sameer Borate he shows you a PHP library that can help not only parse current cron configurations but also provides shortcuts for common timings (ex: "daily" or "weekly").

Working with cron scheduling can many times be a frustrating affair. Although setting a few cron jobs at one time can be easy, calculating cron dates in the future in code can get time consuming quickly. The PHP cron expression parser described here can parse a CRON expression, determine if it is due to run, calculate the next run date of the expression or calculate the previous run date of the expression. You can calculate dates far into the future or past by skipping n number of matching dates.

He includes some examples of putting the library to use to define a cron object based on an expression (either via a shortcut or an actual cron time expression). You can then check to see if the cron is "due" or perform some various operations about its run dates. This includes a formatted output of the previous run time, the next run time and the calculation of the next/previous run time based on a relative timestamp.

If you're relatively new to the PHP language, there's an interesting "shorthand" method for evaluation that you may not know about. In this new tutorial from NetTuts.com they show you this handy method - the ternary operator.

The ternary operator allows us to simplify some PHP conditional statements. We'll see how it can be used, with test-driven development and refactoring, to simplify code.

While the tutorial is largely a screencast, they do provide a quick summary of what the operator is mainly used for and an example for quick reference.

If you're the kind of person that wonders more about the internals of PHP and how it works "under the covers" you'll find this new post from Nikita Popov a good read. It talks about how PHP handles its order of operations in more complex evaluation statements.

At this point many people seem to think that the order in which an expression is evaluated is determined by operator precedence and associativity. But that's not true. Precedence and associativity only tell you how the expressions are grouped.[...] What does this tell us about the order of evaluation? Nothing. Operator precedence and associativity specify grouping, but they do not specify in which order the groups are executed.

He gives a few examples to illustrate his point including multiple increments of the same variable at one time and how it's the "fault" of the compiled variables that were introduced in PHP 5.1. He shows the opcode version of the same PHP userland code and talks briefly about how to avoid this odd functionality in your application.

Michael Nitschinger has written up a post looking at avoiding nulls in your applications in favor of a better kind of value handling - the introduction of "Optional" handling.

While every developer has kind of accepted their existence, they are suddenly there when we'd desperately need them to not show up. How often did you writeif($obj === null) in your PHP code? Can't there be a better, more elegant and fault-tolerant solution to the problem?

His solution is to create a PHP version of this "Optional" functionality (via an abstract class) that allows some evaluation of the returned value from method calls on the object. Methods like "isPresent", "getOrElse", "of" and "fromNullable" make it easier to work with null values instead of just the triple-equals checking. He includes not only the code for the classes you'll need to implement it but examples of it in use - an "Optional" abstract class and two child classes, "Present" and "Absent".