Tag: best practices

PHP Safe and Rector

I came across a couple of very interesting PHP libraries today.

The first one is thecodingmachine/safe.  This library wraps all PHP functions that return false on failure into another function that throws the exception instead. Think of all those file_get_contents() and json_decode() situations you had to code around.  Not anymore.  You can easily have them throw exceptions now.  Read this blog post for more details.

The second one is rectorphp/rector.  It is in fact mentioned in the documentation for the above library.  Rector is a refactoring (reconstruction and upgrade) tool that can easily change large chunks of your code.  Think of function renaming, parameter changes, and such.  Read these blog posts for more details: part 1, part 2, and part 3.

Very handy!

PHP assertions and assertion libraries

I’ve blogged about PHP assertions and assertion libraries a while back.  I haven’t started using the assertions anywhere outside of unit tests yet, but with more and more bloat added to the code to check for types and particular values, I keep coming back to the idea.

Today I came across a nice article by Matthias Noback which once again made me consider assertion libraries in my codebase.  I’ll discuss with colleagues and hopefully we’ll make the decision once and for all on whether assertions are a good way to go forward.

7 Tips to Write Exceptions Everyone Will Love

Tomas Votruba shares the “7 Tips to Write Exceptions Everyone Will Love“.  These all make a lot of sense and are generic enough to be applicable to any programming language (that implements exceptions).  The list of tips is as follows:

  1. Make Exception Names for Humans
  2. Use Quotes Around Statements
  3. What Exactly is Wrong?
  4. What is The Wrong Value?
  5. What File Exactly is Broken?
  6. What Options do I have?
  7. Link what You can’t Fit 140 Chars

Read the full article for both good and bad examples, as well as the explanations of the above.

Semantic Versioning : Version 0 is unstable

We’ve been using Semantic Versioning for quite a while at work now.  It’s easy to explain and follow, and it provides valuable context to the numerous releases of the projects and components that we are doing on a daily basis.

Turns out, however, that I missed a small, but important part of the standard.  All releases in major version 0 are considered to be unstable, so even if they introduce backward compatibility breaking changes, there is no need to increment the major version to 1.  Here’s the relevant quote:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you are relying on the semantic versioning in your projects, make sure to check your dependency management tool, to verify that it handles major version 0 correctly.  Gladly, for us, composer does the job:

The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.