I believe in writing code that is easy to understand, easy to test, and easy to refactor. Yes, I realize that the statement above is pretty general and open to interpretation. Not everyone needs external tools to ensure quality in their code...but, I work on things from time to time that have absolutely no tests. [...] For whatever reason, this happens a lot more frequently in the PHP world. I'm guilty of not writing tests and checking how I write code, sometimes, too. Things are bright, though, for the PHP community - for quite some time now, we've had fantastic tools that assist us in writing better code.

He covers each of the tools, talks some about what they're good for and gives examples of their use, including output. He also talks some about the Pfff set of tools created by Facebook. He also talks some about how these tools fit into his daily work as a part of his pre-commit hooks in git.

I used to look forward to traits as a feature in PHP 5.4, but after discussions with Kore I came to the conclusion that traits are nothing else than static access in disguise. They actually lead to the exact same code smells. Familiar with the outcome of too much static use, we should reject traits as just another way of statically coupling your code to other classes.

He includes some code examples showing traits in use in an example controller to handle a simple redirect. He points out at least six different issues with just this simple implementation. He rewrites it as "static" code to help prove his point. He comes to the conclusion that, much like static methods, traits should be avoided and instead aggregation should be favored.

"Class Oriented Programming" is what people do when they write classes which are all static methods and properties and are never once instantiated. I'll try to explain why this adds virtually nothing vis-a-vis procedural programming, what these people are really missing out on by ignoring objects and why, against all odds, statics don't automatically kill testability. While this article focuses on PHP, the concepts apply equally across many languages.

He talks about code coupling, expectations when using static classes/methods and how it seems a little too similar to some of the procedural PHP we all started out writing. He ponts out that most static method calls are more like function calls than true OOP methods and that their dependencies are a bit more difficult to manage. He suggests that statics are really only good for one kind of thing - dealing with already static data and "utility methods" operating on given data.

I get it: testing is important, and building your codebase in a manner that is easy to test should be a priority. However, sometimes I feel like I have to compromise on the elegance of my code in order to maintain testability. Cases where perhaps a static method makes sense, but end up having to perform some coding acrobatics in order to avoid it. Is this a common challenge, something many developers face and must balance between? Or am I misguided in how frequently static methods can be the most elegant solution (before taking testability into consideration)?

Answers point out a few things - that sometimes, state doesn't matter and static is okay or that they can be used if the instance they return is always exactly the same, never altered.

The real problem that autoloaders solve is to load dependencies. [...] The normal logic that's used to justify autoloading over manual dependency loading in production is that it only loads the classes you need. Therefore you save the parsing costs of classes that you don't need. But surely that additional run-time loading has costs. So I decided to setup a test to see how expensive that additional run-time loading costs us, and to prove whether or not autoloading is worth it in production.

He gives an example of the two methods - using the spl_autoload_register method to define a loader and loading them with a defined file path instead. He found the autoloading version slower than the hard-coded (by quite a bit) but how, when the number of files is reduced, the performance gets much closer. He also briefly looks at two other pieces of file-related functionality: file_exists and require_once.

One of the features originally planned for PHP 5.4 was scalar type hinting. But as you know, they weren't included in the release. Recently the topic has come up again on the mailing list and there has been a hell lot of discussion about it. Yesterday ircmaxell published a blog post about his particular proposals. The reactions on reddit were mixed. On one hand it is clear that people do really want scalar type hints, on the other hand they didn't seem to like that particular proposal.

He gets into some of the details of some of the current proposals and their problems like the strict versus loosely-typed nature of PHP and type hinting that was included but not enforced. One he does like, however, is one based on casting - how the variable ends up being cast rather than the specific type it is when it comes into the function/method. This one still has its flaws, so he suggests another method - weak type hints but with stricter input validation (without casting). He also briefly mentions something called "box based type hinting" that would allow users to define their own hinting rules.

Don't worry - code examples (pseudo-code obviously) are included for each of these proposals to help you understand the differences.

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

I have been tinkering with CLANG's static analyzer lately. This post summarizes how I installed LLVM and CLANG and performed the analysis of a build of the PHP interpreter.

He includes all the commands (unix-based) to get the clang tools/libraries installed in the correct places as well as what to add to your $PATH to get the "scan-build" command to work with the make and make install parts of the PHP compile process.

My interest was mostly because I'm working on a book chapter which includes some static analysis content, and there are a couple of these tools that I include in my own builds, but I don't do much with the output of them. However I didn't want to drop anything from the chapter if it was actually a valuable tool and I was just missing the point - pretty much all the tools got a good number of votes though, so I'll be covering all of the [options].

According to her results, the most used tool by developers is the PHP_CodeSniffer with the PHP Mess Detector and PHP Copy & Paste Detector tied for second place.

It came out almost 2 years ago, but it to me that many programmers around me have no idea about it. Myself, I have learned about it around 6 months ago. The PHP documentation defines late static binding as a way to "reference the called class in a context of static inheritance." This definition didn't really help me the first time I read it. Fortunately, there are more explanations in the documentation, and there are good examples. If you haven't, you should read it.

To clarify, he includes a code snippet showing the use of the "static" keyword to correctly reference a static method. He also includes in interesting bit about when's a good time to use it.