Like the mythical Cassandra, I occasionally find myself aware of an impending disaster but unable to prevent it. The particular disaster I am talking about is writing verbose, ugly, unclear code in PHP that can be written succinctly, beautifully, and readably in Groovy (or at least one out of those three). This would not feel so ironic, were it not for the fact that I never have quite the fluency with Groovy to actually be able to write the alternative code, and thus I am forced to go with the PHP solution that I know to be suboptimal. A recent case, in particular, has highlighted this fact to me, as I had the task of turning a hash (actually a list of hashes) into a CSV file (actually a string in CSV format), while filtering the hash based on a whitelist of keys. Although this turned out to be implementable in 7 lines of PHP, I was sure it must be a one-liner in Groovy.
In a simple computer program, we like to imagine the flow of execution starting at the top and moving down line by line until it reaches the bottom. Sure, it might skip some lines if a condition for executing them is not met, or it might run some lines several times if there is an instruction to loop, but there shouldn’t be any reason for, say, a four line script to execute lines in an unexpected way. Indeed, PHP does execute code in the expected way, but as long as you have spent a bit of time thinking about what the “expected” way should be. To save you the trouble of having to think about this after writing some code which doesn’t work, and wondering why it doesn’t work, I will present an example of how PHP treats “jumping” in a four line script, and what that I mean by that term. Hopefully anyone who reads this will then want to avoid jumps in their code, as they will consider the practice harmful to the goal of writing maintainable software.
