PHPMetrics is yet another tool for static analysis of your PHP codebase. It aims to provide a simpler and easier to understand report, than all those other tools in the PHP ecosystem today.
Tag: best practices
JSON API? No … HAL!
Wait, what? That’s exactly what I said when I read this blog post. I am still making my way through the JSON API specification. And now it seems I might be wasting my time, as I should be learning HAL.
Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.
HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.
Sometime I think that I should just stop learning. What’s the point? By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.
Meh…
PHP Package Development Standards
Paul M. Jones announces the availability of PHP Package Development Standards for review:
This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.
PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.
Have a look at php-pds/skeleton GitHub repository.
Personally, I welcome this initiative. PHP ecosystem exploded in the recent years with the help of composer and Packagist.org. There are over 120,000 packages just on the Packagist.org. I think, it’s good to have some standards and best practices. The PHP Framework Interop Group (PHP-FIG) is doing its best with the PHP Standards Recommendations (PSRs). But we could have some more guidelines in order to have some consistency.
PHP Package Development Standards takes, in my opinion, the right way of looking at what’s out there, what works and what doesn’t, and than setting the guidelines based on the real world practices. They cover things like file and directory naming conventions, versioning, changelog and licensing – which are common issues for pretty much every package.
Looking at the packages that I am involved with, only a few minor changes are necessary to comply. Mostly, the “config” folder instead of the Unix-style “etc“, CONTRIBUTING file, and a CHANGELOG file, which I’m still to find a good way to semi-automate.
100 Favorite Programming, Computer and Science Books
Peteris Krumins, of the Browserling fame, has a series of blog posts on his top favorite programming, computer and science books. It’s an excellent selection of titles, from which I’ve read only a fraction. Good timing for the Christmas shopping too. Here are the blog posts in the series so far (5 books per post):
- Part one. Note to self: read “The New Turing Omnibus”.
- Part two.
- Part three. Note to self: read “The Unix Haters Handbook (free pdf)“, buy (again!) “Unix and Linux System Administration Handbook” or find who has any of the three previuosly purchased copies.
- Part four.
- Part five.
- Part six. Note to self: read “The Unix Philosophy”.
Even with the 30 books mentioned so far, there are new things to read and learn. I wonder how many of the notes to self I’ll have by the time the whole 100 are listed.
Quick and easy introduction into PHP Mess Detector (PHPMD)
PHP Mess Detector is yet another one of those tools that help to keep the code base manageable and clean. Here’s the description straight from the site:
What PHPMD does is: It takes a given PHP source code base and look for several potential problems within that source. These problems can be things like:
- Possible bugs
- Suboptimal code
- Overcomplicated expressions
- Unused parameters, methods, properties
Here is how you can jump right in. It’s super easy. It only takes 6 steps.
Step 1: Pick a project to try it on.
You can use any of your own PHP projects, or grab one from GitHub. It doesn’t matter. You’ll know better where to apply it once you get comfortable with the tool. For sake of this quick guide, I’ll use one of our Open Source repositories – cakephp-groups plugin.
cd /tmp git clone git@github.com:QoboLtd/cakephp-groups.git cd cakephp-groups
Step 2: Install PHPMD with composer.
composer require phpmd/phpmd
Step 3: Run PHPMD.
If you run “./vendor/bin/phpmd“, you’ll see a help screen. But what’s the purpose of this blog post if you have to read the manual, right? So, let me simplify it for you. PHPMD needs three parameters:
- Path to the PHP source code that it will be examining. We’ll use “src/“.
- Report format – one of: xml, text, or html. We’ll use “html“.
- A choice of mess detection rules that you want it to apply. You can create your own, or you can pick one from: cleancode, codesize, controversial, design, naming, unusedcode. We’ll use “unusedcode“.
Also, we’ll give it an extra one: “–reportfile“, because by default PHPMD will spit everything to the standard output. So, let’s put it together and see what we’ve got.
phpmd src/ html unusedcode --reportfile phpmd.html
Step 4: Examine the report.
After running PHPMD command above, you’ll find a phpmd.html file in the same folder. Here’s how it looked for me, when open in the browser.
So, PHPMD found one problem in the “src/Shell/Task/ImportTask.php” file on line 93. Here’s the relevant piece of code:
protected function _getImportErrors($entity) { $result = []; if (!empty($entity->errors())) { foreach ($entity->errors() as $field => $error) { if (is_array($error)) { $msg = implode(', ', $error); } else { $msg = $errors; } $result[] = $msg . ' [' . $field . ']'; } } return $result; }
As you can see (line 09 above is line 93 in the report), the issue reported by the PHPMD is a typo in the variable name. It should be $error, not $errors.
Step 5: Fix the problem.
- Rename the $errors variable to $error.
- Rerun the PHPMD report as per Step 3.
- Examine report as per Step 4 to make sure that the problem is fixed and no new issues were introduced.
- Create a new branch.
- Commit the code.
- Push the branch to GitHub.
- Create the Pull Request.
All of the above mini steps took about 7 seconds.
Step 6: Pour yourself a drink.
You’ve just learned how to use a new tool, found a bug, and submitted a patch to the Open Source project. At least I hope you did.
Not bad at all.
If you are wondering what to do next, here are a few suggestions:
- Try running PHPMD for other types of issues. As I said, it supports cleancode, codesize, controversial, design, naming, unusedcode, and we’ve only ran it for the “unusedcode”. See what else is there.
- Integrate PHPMD into your projects, to run automatically, together with your unit tests. You do have automated unit tests, right?
- Customize the ruleset that PHPMD is using to find more/less issues, which are maybe more specific to your project.
- Use your newly acquired knowledge to fix issues with more Open Source projects. You’ll make a name for yourself and you’ll make a world a better place.
Let me know how it goes.