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.

Igor Wiedler has shared some of his thoughts on his site today about the "heaviness" of things that call themselves "microframeworks" and why it may not be about the amount of code involved at all.

Quite often silex has been described as heavy or bloated. It's time to put this myth to rest. [...] Micro-framework What an excellent buzzword! Let's face it, this is an overloaded and mostly nebulous term. I don't think it's possible to clearly define what it means. [...] But the real answer lies in what silex doesn't do.

He suggests that the "micro" in "microframework" is more about it providing a limited amount of features (bare-bones) versus a more full-featured, possibly full stack framework. He talks about the dependencies that Silex currently has and provides some statistics about it and these packages it depends on. He also briefly mentions the minimal interface the framework provides, citing the few components you'll probably touch in your work with it.

In this new post to his blog Keith Casey looks at a metric he considers a true failure at measuring the success of a piece of software - lines of code.

While the obvious implication of the article is that organizations are not properly equipped/trained/prepared to tackle these large software development projects and therefore eventually fail. Especially early in my career, I tried to tackle problems and ideas that simply weren't reasonable or were considered ridiculously complex and far beyond my skills. This is a common problem on software development teams with little real-world experience or hubris in their own skills or both...

He doesn't see the Lines of Code (LOC) metric as particularly useful and backs it up with a few reasons including the overwhelming complexity of large codebases, duplication in functionality from place to place and the amount of "cruft" code that can accumulate in older, less used parts of the code.

On the Blue Parabola blog Keith Casey asks the question "how do you measure an individual's contribution?"

In the past few weeks, I've been working fast and furious at getting web2project to our v1.0 milestone. As part of that effort, I track open issues, problematic modules, community feedback via the forums, death threats via all methods, and other related aspects.

He suggests a few different ideas for measuring how much a user has contributed: lines of code, commit count, issues they've reported, number of issues closed or community involvement. Of course, none of these can truly measure how much an individual has participated in a project, especially since it could be a mix of several of them combined into a whole as the "involvement persona" of any given person.