In this post to his site Matt Stauffer shares several methods you can use to count the total number of lines of code in a PHP project.

I'm giving a talk soon about Laravel and "the enterprise", and the concept of LOC (lines of code) keeps coming up. It turns out that's actually a much harder number to discover than you might think, so I figured I would write up a few options here.

For what it's worth, I'm not a big fan of LOC as a measure of any importance, but it can at least give us some broad foundations to use to talk about broad differences in project size. If you were to ask me, I would say we shouldn't even think about it. But we don't always have that luxury.

He starts with a tl;dr for those that want the quick win (use PHPLOC) but shares other options with different tools too:

• https://github.com/AlDanial/cloc - a smarter version of PHPLOC that accounts for empty lines, comments, etc
• the Statistic plugin for PHPStorm
• a regular expression match for use in Sublime Text
• manually from the command line using find
• using the Silver Searcher tool

He shares answers to a few FAQs about finding lines of code and the output of each tool/command on the same project to show the differences.

In his latest post Pádraic Brady talks about lies, damned lies and code coverage and how that relates to something called "mutation testing."

I spent the vast majority of 2014 not contributing to open source, so I kicked off 2015 by making Humbug available on Github. Humbug is a Mutation Testing framework for PHP. Essentially, it injects deliberate defects into your source code, designed to emulate programmer errors, and then checks whether your unit tests notice. If they notice, good. If they don’t notice, bad. All quite straightforward. [...] This article however is mostly reserved to explain why I wrote Humbug, and why Mutation Testing is so badly needed in PHP. There’s a few closing words on Mutation Testing performance which has traditionally been a concern impeding its adoption.

He starts off by talking about the idea of "code coverage" when it comes to writing unit tests...and how 100% coverage usually ends up being a lie. He points out that the current methods of line-based coverage metrics can lead to false results and that it's more about test quality rather than volume of tests. He then moves into talking about mutation testing and where it fits in the test quality puzzle. Finally, he mentions one thing to watch out for when trying out mutation testing and the performance jump (longer, not shorter) it can introduce into your testing cycle.

Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

On the Ibuildings techPortal today there's a new article from Lorna Mitchell looking at the phploc tool as a way to analyze your code and pick out a whole selection of statistics.

This has been a feature of PHPUnit for some time but has been released as a separate project in the phpunit pear channel. The nature of PHPUnit means that many of these statistics can be collected while the tests are running, which is why it was added to that tool in the first instance.

Stats gathered include the number of directories, files, interfaces, methods, functions and constants with more details for each (like visibility, actual lines of code contained in them and the cyclomatic complexity). The tool is very simple to use - just call it from the command like and give it a path to your codebase. It does the rest and spits out a text-based report.

The IBM developerWorks site has a new tutorial posted (registration/login required) talking about image creating in PHP using the GD library.

The purpose of this tutorial is to show you how to get started with the GD library and to provide a variety of techniques you can apply to your Web-page coding. The tutorial doesn't cover every GD function, but it teaches you the basics. The Resources section provides Web sites where you can learn more about using the GD library.

They go through the creation of sample images, working with gradients and lines, adding text, saving the image data out to a file and how to work with existing graphics to modify them.

In another part of their series of excerpts from the Zend PHP Certification Guide (from Zend), DevShed has posted this article talking about debugging and performance issues and methods.

Making mistakes is human, and so is fixing them. In your day-to-day programming adventures, it's inevitable to introduce bugs in your PHP code, especially when you're writing very complex applications with tens of thousands of lines of code spread across tens of files.

In this article they look at things like flattening if statements, spplitting single commands across multiple lines, and the difference between =, ==, and ===.

In another part of their series of excerpts from the Zend PHP Certification Guide (from Zend), DevShed has posted this article talking about debugging and performance issues and methods.

Making mistakes is human, and so is fixing them. In your day-to-day programming adventures, it's inevitable to introduce bugs in your PHP code, especially when you're writing very complex applications with tens of thousands of lines of code spread across tens of files.

In this article they look at things like flattening if statements, spplitting single commands across multiple lines, and the difference between =, ==, and ===.

On Tobin Bradley's blog today, there's a follow up to a previous artcile posted concerning getting MapServer working on a Windows/IIS install. This time, they show how, with a few lines of PHP code, you can create a map quickly and easily.

PHP/Mapscript makes this fantastically easy, with only 19 lines of code! You can download the code here.

The remainder of the post steps you through the process of installing the script and, with a few simple calls, you have a functional map of your chosen location.

On Tobin Bradley's blog today, there's a follow up to a previous artcile posted concerning getting MapServer working on a Windows/IIS install. This time, they show how, with a few lines of PHP code, you can create a map quickly and easily.

PHP/Mapscript makes this fantastically easy, with only 19 lines of code! You can download the code here.

The remainder of the post steps you through the process of installing the script and, with a few simple calls, you have a functional map of your chosen location.