Constants are named values that do not change. You’ve probably used them many times to set a value that you want to persist throughout your codebase. In this short post I’m going to look at a couple of ways we can use them to improve our code. We’ll look at how they can be used to reduce bugs and make our code more readable.
The examples here will be PHP related, but what is being discussed should be applicable elsewhere.
Using Constants for Associative Array Keys
Where we need to use strings for the keys of an associative array it can sometimes be a good idea to use constants instead of a hard-coded string. Why? Well to start with it can help us eliminate typos in our code.
For example, lets say we are making HTTP requests using the popular PHP HTTP client Guzzle.
$response = $this->client->post($url, [
'json' => ['foo' => 'bar'],
]);If we had accidentally typed 'jsonn' or some other typo for our array key the code would fail due to a silent bug in our code. It may not be instantly obvious that the code isn’t working due to the mistyped key.
Instead of writing 'json' as our array key we could use Guzzle’s associated RequestOptions constant:-
$response = $client->post($url, [
\GuzzleHttp\RequestOptions::JSON => ['foo' => 'bar'],
]);If we mistyped the constant here, instead of getting a silent bug PHP would raise an error. This makes finding the problem in our code much easier.
Another benefit of this approach is that the code can be documented more easily. Take a look at Guzzle’s RequestOptions class and you will find a well commented list of available request options that we can use.
Using Constants to Avoid Magic Numbers
Magic numbers are numbers that are directly used in code without a definition of what the value represents. These can make code difficult to read and they generally lead to hard to maintain code (e.g. if a value needs to be updated throughout the code). To avoid magic numbers we can define constants for the values and use the constant whereever a particular value is required.
For example, Symfony provides a set of constants for the HTTP response codes as part of its Response class. While for the majority of us the number 404 is hopefully instantly recognisable, using Response::HTTP_NOT_FOUND is more explicit.
Seeing Response::HTTP_MOVED_PERMANENTLY is also more instantly readable than seeing 301 in the code; if you are like me you might take a brief moment to check in your head whether that’s a permanent or temporary redirect response if it had just been the value in the code.
As with using constants for associative array keys, using constants for common values in our code can reduce the risk of bugs arising from typos. Typing 301 in your code when you actually meant 302, a temporary redirect, could clearly lead to some undesired logic. Using the defined constants reduces the risk of you typing the wrong value.
Do It Yourself
The two examples I’ve given here are both from popular open-source projects. If you’re using them then I’d recommend you start using the constants they have already defined. However, hopefully you’ve seen the value in adopting their approaches to your own code.
How you define your own constants is up to you, but I particularly like the way Guzzle has a class just for setting up a collection of related constants and the way it provides documentation for the code.