Traits were introduced in PHP 5.4 on March 1st, 2012. Traits provide support for horizontal code reuse, but what is meant by horizontal reuse? Should we be using traits? This article explores what traits are and when we should use them as well as when we should not.

What is a trait?

Anthony Ferrara said it best when he wrote in a StackOverflow answer that:

[Traits are] basically just automated copy and paste*.

Unlike manual copy and paste, traits ensure all copies of the code remain consistent—changes to a trait are reflected in all classes using that trait, which is desirable when each copy represents the same idea. Since everything inside a trait is copied directly into a class, even private members of a trait are accessible to the class composing that trait.

Traits are different from includes because include statements can only contain complete classes whereas traits can only represent class fragments. Even if our trait could conceptually function by itself, it is unable to do so because we cannot create instances of traits – the trait must be composed by a class.

Traits were added to PHP to provide horizontal reuse. Horizontal reuse is the corollary of vertical reuse, better known as inheritance. When we create a class hierarchy by extending classes it can be said we are extending vertically. When we compose traits in our classes it can be said we are extending horizontally. Although a class can only extend one other class we can use as many traits as desired.

As Ferrara points out, traits in PHP are actually mixins, which means we can not only declare behaviour but also state in a PHP trait. While the formal definition of a trait permits only method declarations, in PHP we can also define member variables, which means they're actually mixins!

Mixins are found in many modern scripting languages including Ruby, Python, JavaScript and, of course, PHP; however they seldom make an appearance in compiled languages like Java and C variants. Even amongst languages that support them, we can usually express solutions to our problems without using traits at all. So do we even need traits? When should we use a trait?

* Note that traits are not strictly the same as copy and paste. A class can compose two traits: one which specifies an abstract method and another which specifies a concrete implementation of the same method. Normally, if we specify the same method name twice in our class we would get an error stating we cannot redeclare the method, but when this ocurrs with traits PHP will resolve the conflict so long as the method signatures are compatible.

When should we use traits?

Whenever we have code duplicated in our application we should find a way to eliminate the duplication and reduce our technical debt. Code duplicated n times must be modified in n places when we need to make a change; therefore we would like to ensure that n = 1 such that any change is only made in one place. By reusing code we eliminate duplication.

Traits are just one option for code reuse; we should also consider inheritance and composition. To help decide which solution to use we can apply the following rule.

Traits should be used when we want to reuse code but inheritance and composition are both unsuitable.

Following this rule we can decide how to implement code reuse. The decision tree for this rule looks like the following.

Using this model we can explain, for all cases, why traits are an appropriate or inappropriate solution for code reuse. Let's apply this model to a real example.

Reusing entity fields

Notice that, according to our decision tree, a trait is always the last option we consider. We always consider inheritance and composition first; a trait is a last resort when no other option is available to us - and this is good - because traits are difficult to test in silo so we should use them sparingly.

Why not traits

• You don't need a trait! Why not just a static class.
• They're hard to test.
• They hide functionality from the reader.

Summary

We can summarise usage of traits by applying the following rule: do not use traits unless absolutely necessary. Some problems that can only be solved with traits and these are the only problems traits should be used to solve. It is therefore our responsibility to first determine whether a problem can be solved without traits, and if it can, prefer those solutions.

Thanks to some sick Git magic, I was able to save a PR. rerere replays successful conflict resolutions in other branches. It has to be enabled with a config setting: git config --global rerere.enabled true. However, it has to be enabled at the time the merge process begins. Since I had already resolved the conflicts it was of no help.

However, thanks to some even sicker Git magic I was able to replay the merge commit with rerere enabled so it could learn about the conflict resolutions it had previously missed, using the following steps:

2. git log -1 – Note the merge commit hash.
3. git reset --hard HEAD^ – Undo the merge commit.
4. git merge origin/develop – Begin merging again. rerere reports it is watching the merge.
5. git read-tree --reset -u mergecommit – Reset the state of the tree to the original merge commit.
6. git commit – Complete the merge with the original resolutions applied. rerere learns about the resolutions.

At this point we can return to the other branches and merge develop and let rerere apply the same conflict resolutions to them.

Code reviews are quickly becoming an industry standard practice for improving software quality. Open source workflows slowly become business best practices as businesses start to appreciate the costs of technical debt and become more concerned with software quality. Over the past decade, the absence of unit testing in the workplace eventually turned into a required developer skill. The days of submitting our first draft as a finished piece of work are gone: peer code reviews are the next developer core competency for software quality, inherited from social coding features of popular open source coding platforms like GitHub.

GitHub released its formal code review workflow just a few months ago, but informally, code reviews have been a foundation of the platform for years thanks to features like pull requests and inline comments. Its competitors, such as BitBucket and GitLab, share similar features. Code review tools also exist for self-managed solutions, like JIRA plug-in, Crucible.

Code reviews mean we no longer work by ourselves: coding is a social process. Even if we write code by ourselves, at least one other person will check it before it is committed to a shared repository. This has the potential to create conflicts between developers as two or more persons with strong opinions inevitably collide. This is something we're all susceptible to: sometimes we fail to remain humble or objective in the face of criticism of our work, but it is not just the reviewee's fault when conflicts occur; sometimes the reviewer hasn't done a good enough job writing the review.

Writing effective code reviews

How do we write good code reviews? A detailed guide to code reviews has been published by thoughtbot and even adopted by GitLab, and it's a great read, but this article proposes effective code review with just two simple rules.

1. Identify a problem.
2. Propose a solution.

For every comment we make as a reviewer we must ensure both rules are followed: it is insufficient to do just one of these things. But all too often, a reviewer will leave a comment that does just one, which is often why conflicts and frustration occur between author and reviewer. Let's look at each rule in more detail to see why both are important, but by themselves are insufficient.

Identify a problem

Identifying a problem is crucial to establishing that a change is necessary. If there is no problem, why should the author feel compelled to make a change? Offer objective evidence that establishes a problem really exists and thus incentivise the author to make a change.

Sometimes we identify a problem but don't have a solution to offer. It is not strictly incorrect to leave such a comment on a review, but such comments often offer little value because if we don't have a solution there's nothing to suggest the author does either. If we're lucky, someone else might have a solution, but it is incorrect to require the author to make a change based on a problem without a solution because we wouldn't be able to do a better job ourselves.

Propose a solution

Take the time to propose at least one solution to the problem. Nothing motivates the author to revisit their code to make a change like seeing a better solution well presented. If we can propose several alternatives, all better than the original, this empowers the author to choose the one they prefer, further encouraging them to make a change. Don't be afraid to write code in a review: someone has to write it, and there's no reason why the original author has to do all the work, because social coding is a collaborative process through which the best results can only be delivered by working together.

However, beware of proposing solutions without establishing the existence of a problem! This is the most common mistake made by inexperienced reviewers whom state, do it this way instead, without establishing why. If we cannot explain why our solution is better than the current implementation the author is not compelled to make a change. Sometimes our instincts are correct, our solution is better, but we must develop the skill to objectively express why our approach is better. Never assume it is obvious to the reader that we are correct without offering proof.

Sometimes our solution is not better, it is just different. Sometimes, through trying to prove our solution is better, we realize even before publishing our comment that it isn't better, it's just an alternative. In this case we're just inflicting our personal preferences on others; this is why it's paramount to identify the problem before proposing a solution.

Before submitting code for review

The focus of this article is on writing code reviews, but it would be remiss not to mention the author's responsibility when submitting code for review. When we submit code there is just one simple rule to follow.

1. Never submit the first draft.

The first person to review our work must always be ourselves. It places an unfair burden on the reviewer and wastes their time to spot mistakes we could have found ourselves. Every problem the reviewer identifies in our work should teach us something new; if it does not, we didn't do a good enough job checking our work before submission.

Summary

Code reviews are becoming commonplace both with collaborators in online communities and with colleagues in the workplace. By following two simple rules we can ensure we write better code reviews, reducing the chance of conflicts and frustration through miscommunication, and insodoing gain the respect and admiration of our peers for helping them write better code together with us.

And remember: don't be too hard on others, or yourself; we all make mistakes.

Correctly naming things is the most difficult programming task, along with other documentation tasks. However, this is only because we often afford these tasks insufficient consideration. As with most things, the more we do it the easier it becomes. In this article we will discover how to choose correct names for our methods to help ourselves and others read and understand our code.

Although we will focus on naming, documenting and naming complement each other very well. Once we get into the habit of writing documentation for each method, describing what the method does, this helps us name our method correctly. If the documentation is good, usually it is possible to name a method correctly just by picking words from its documentation. We can even use this technique to verify that the method name and its documentation are correct by making sure they agree with each other – if they say different things one of them is wrong.

Lets establish our first and most important rule: all functions and methods do something so they should begin with a verb (a doing word). Now we're going to look at how to choose the best verbs to convey the most meaning for what our methods do.

Get less

The majority of methods we write will return a value and it's a common fallacy to choose get as the verb for too many of these methods. Get is fine for accessor methods that perform simple operations like dereferencing a pointer but doesn't communicate enough information to the caller about the complexity of less trivial methods.

Consider a method that fetches data from a database. It may connect to a remote computer, search for data from multiple sources, perform aggregation and sorting. We could call this method getData() but its verb does not differentiate it from another method that merely gets a simple value already stored in memory. By calling our method fetchData() we imply more work has to be done to retrieve the data.

As a rule, use get only for methods with constant time complexity; for anything more complex select a more descriptive verb. For example, if we write a method that uses arithmetic operations to calculate the return value, prefer the verb calculate.

Try to describe what the code in the following method does.

function getItem($match) {
    foreach ($this->items as $item) {
        if ($item === $match) {
            return $item;
        }
    }
}

We could say this method appears to be searching a collection of items to find one that matches the specified match parameter. From this description we can directly extract a better verb than get; in this case either search or find does a better job of conveying to the caller the complexity of retrieving an item, so we should rename this method, findItem.

Do not do

Since all methods do something, choosing do as our verb does not convey any additional information about what our method is doing. Do is one of several common cop-out verbs that should be avoided, along with handle, perform, return, compute and other synonyms.

Some verbs, such as call, execute, run and prepare, perch on the boundary of suitability. It is not always wrong to use these verbs, but if we find ourselves wanting to use them, first pause to consider whether there is a more specific verb to describe what the method is doing.

Boolean return types

Methods that return true or false should begin with is, are, was, were or a modal verb. Modal verbs include can, could, may, might, must, shall, should, will or would. These methods pose questions such as Button::isEnabled(), Inputs::areValid() or User::canAccess().

An alternative convention found in Ruby is to define questions by appending a question mark instead of prefixing a verb. The methods from the previous examples would be named Button#enabled?, Inputs#valid? or User#access? respectively. You may wish to use this convention if your language supports this syntax.

Subject inference

There is a subtle but important difference between functions and methods. A method is a function that runs in the context of an object, such as those we define in a class. We say that the method is bound to the class or object because when it runs it has access to the data stored in that object.

Sometimes it is sufficient to just use the verb when the subject can be inferred from the bound object. For example, a method that saves a message may be called saveMessage. This method includes a subject (message) which specifies the subject of the operation. However, when the subject is the same as the name of the object our method is bound to, we can eliminate it and simply call our method, save. The subject is inferred from the bound object and reads intuitively: $message->save() as opposed to $message->saveMessage().

Do not describe parameters

A method's signature comprises both its name and its parameters. When using a method, we have access to both, so it is just duplication to describe the parameters in the method name. The method signature findUserByUserIdAndToken($userId, $token) can be simplified to findUser($userId, $token).

In languages that support method overloading, such as C++, C# and Java, we can always follow this rule. However, most popular scripting languages such as JavaScript, PHP, Python and Ruby do not support method overloading, meaning we cannot have two methods with the same name but different parameters. In this case it may be necessary to break this rule in order to differentiate between multiple versions of a method.

Summary

We learned some semantic rules that can be applied to our functions and methods to help determine the correct names. Most importantly, all method names must begin with a verb. If we describe what our method does, and take care to avoid cop-out words, we should be able to select the most appropriate verb to begin our method names.

Some consider documentation more important than code. If code goes wrong and there's no documentation it's difficult to fix because we may not know what it was supposed to do, or why. When a system is clearly defined in descriptive prose we can make informed decisions about the best way to fix it. Correctly naming methods is the first step towards good documentation but to take it a step further we should consider documenting every class and method too, and in turn, this will help us name our methods.

Coercion is implicit typecasting for scalar types (integer, float, boolean and string). In this article we look at how we can use coercion as an elegant alternative to explicit typecasting.

Coercing to integer

We can coerce any expression to integer by suffixng |0 – bitwise or operator followed by zero. Bitwise operators only work on integers so PHP coerces both operands to integer before performing the operation. Performing bitwise or with a value of zero has no effect on the numeric value so we just benefit from the integer coercion.

Integer coercion is equivalent to (int)floor($x), intval($x) or typecasting with (int)$x or (integer)$x. In some languages this can also be achieved by prefixing ~~ – two not operators.

Examples

Coercing to float

We can coerce any expression to float by suffixing +0. or +.0. Floating-point numbers can be specified without the exponent or significand (but not both), in which case the unspecified part is presumed to be zero; that is, 0. and .0 are the same as writing 0.0.

Float coercion is equivalent to floatval($x) or doubleval($x) or typecasting with (float)$x, (double)$x or (real)$x.

Examples

Coercing to numeric

We can coerce any expression to numeric; that is, an integer or float, by prefixing + or -. Although typically used for addition and subtraction as arithmetic operators, when applied to only one operand we call them unary plus and minus because they only operate on one operand. Unary plus converts its operand to either int or float depending on which is most appropriate; unary minus does the same but also flips the sign.

Numeric coercion cannot be achieved with any other built-in PHP function or syntax.

Examples

Coercing to boolean

We can coerce any expression to boolean by prefixing at least one ! – logical not operator. Logical operators always return a boolean value. We use the not operator because it offers the most concise syntax as the only unary logical operator. The not operator also inverts the meaning of the expression but prefixing a pair (!!) preserves the meaning.

Boolean coercion is equivalent to boolval($x) or typecasting with (bool)$x or (boolean)$x.

Examples

For more conversions see the true/false columns of the loose comparisons truth table.

Coercing to string

We can coerce any scalar or objects implementing __toString() to string by enclosing them in double quotes.

String coercion is equivalent to strval($x) or typecasting with (string)$x.

Example

Exception implements __toString() providing a string representation of the exception.

$e = new Exception('foo');
"$e";

exception 'Exception' with message 'foo' in -:2
Stack trace:
#0 {main}

Practical applications

Some people have tried to agument the language to provide strong typing for scalars but by working with the grain of the language and embracing coercion we can ensure variables are the types we expect much more easily.

Mutator example

Coercion is useful when writing getters and setters. In the following example we want to ensure only integer values are stored in our class when its setInteger method is called.

class Bar {
	private $integer;

	public function setInteger($integer) {
    	$this->integer = $integer|0;
    }
}

ToString example.

We want to implement __toString in our class and it is paramount that our implementation actually returns a string to avoid PHP throwing a fatal error. We could use typecasting but coercion solves the problem elegantly.

class Foo {
	public $value;
    
    public function __toString() {
    	return "$this->value";
    }
}

$foo = new Foo;
$foo->value = 123;
"$foo"

'123'

Summary

Conclusion

We explored coercion as a terse alternative to typecasting that works with PHP's concept of type juggling to modify the type of an expression by manupulating its context. Although these examples apply to PHP the concept of coercion can be applied to many scripting languages to modify the types of expressions.

We want to find regular expression delimiters that enable us to avoid inserting additional escape sequences into our patterns. This is ideal when we want to inject foreign patterns where we can't guarantee which characters will be used.

The regex grammar table helps understand the language used in this article. You should also know that metacharacter means any character which has special meaning in regex patterns.

PCRE knows no delimiters

PHP provides regular expression support using the Perl Compatible Regular Expressions (PCRE) library written in C. Perl has the most comprehensive regex features supporting powerful constructs such as assertions, conditionals and recursion allowing more problems to be solved more easily than other regex flavours.

However, PCRE does not provide a way to specify regular expression options (modifiers) within the pattern; that is, the pattern and options are passed separately to the compiler as shown by the following method signature.

pcre *pcre_compile(const char *pattern, int options, ...);

It is up to implementations like PHP to decide how to expose modifiers to us. Most implementations map each option to a single letter such as the i modifier which sets the PCRE_CASELESS option enabling case-insensitive matching. Modifiers are typically appended to the pattern and separated by delimiters but PCRE itself has no concept of delimiters.

Delimiters in PHP

Most implementations use a pair of slashes to delimit patterns, for example, /pattern/. In PHP we may elect any symbol (except backslash) to delimit our pattern with the crucial caveat that each occurrence of our delimiter within the pattern must be escaped by prefixing a backslash (\), as shown below.

• /a/b/ – invalid
• /a\/b/ – valid
• #a/b# – valid

We'd like to be able to choose a delimiter that will never appear in our pattern to avoid having to insert unnecessary escapes. If we're hard coding our pattern this should be possible even if we have to change the delimiter a few times as our pattern evolves. However, if we need to insert a user-defined pattern how can we ensure that our chosen delimiter will not conflict? The solution lies in asymmetric delimiters.

Asymmetric delimiters

We may never know why PHP is unable to detect the last occurrence of our delimiter without requiring us to escape every occurrence before it but fortunately there is another solution. PHP inherits Perl's bracket delimiter syntax giving us four asymmetric delimiters to choose from:

• (pattern)i – round brackets
• [pattern]i – square brackets
• {pattern}i – curly brackets
• <pattern>i – angled brackets

Angled brackets

Each pair of brackets except for angled brackets are considered metacharacters in patterns but have no special meaning as delimiters. Since angled brackets are not metacharacters we might think we could avoid having to escape them in patterns delimited by angle brackets.

• <>> – invalid
• <\>> – valid
• <<> – invalid
• <\<> – valid

Unfortunately, angled brackets have to be escaped when used as delimiters just like symmetric delimiters, except now we've inherited the burden of having to escape two characters instead of just one! Angled brackets are a step backward but the other three bracket types offer something different.

Non-angled brackets

When we use non-angled brackets as our delimiters we can still use whichever bracket type we choose as normal in patterns without having to escape them and without changing their meaning – exactly what we've been searching for! Each of the following expressions match the character a once.

• ((a)) – valid
• [[a]] – valid
• {a{1}} – valid

The ideal delimiter

We have been searching for a delimiter that does not require us to insert additional escapes into our pattern and any of the non-angled brackets serve this purpose, but we still have to choose one of them, so which is best?

Technically each options is as good as the other but curly brackets are the least common metacharacter of the three, and as a quantifier, cannot appear at the start of an expression so they can only double-up at the end. This sets curly brackets apart as the most suitable delimiters to use in PHP.

Conclusion

Three different asymmetric delimiters allow us to avoid extra escaping: round brackets (), square brackets [] and curly brackets {}. As the least used metacharacter, less likely to be confused with other parts of a pattern, curly brackets may be the ideal delimiters for most expressions.

We briefly review the major new PHP language syntax introduced in each version since 5.3 – the version that birthed the features that paved the way for the prevailing PHP renaissance.

Features are ordered by how frequently you are likely to use them from a practical programming perspective according to the table.

If a feature does not appear in this reference it is because it is not syntax or is a minor modification of existing syntax.

New in PHP 5.3

Released June 30th, 2009.

New in PHP 5.4

Released March 1st, 2012.

New in PHP 5.5

Released June 20th, 2013.

New in PHP 5.6

Released August 28th, 2014.

References

1. http://php.net/manual/en/migration53.new-features.php
2. http://php.net/manual/en/migration54.new-features.php
3. http://php.net/manual/en/migration55.new-features.php
4. http://php.net/manual/en/migration56.new-features.php

Correctly merging two arrays into a single array requires thinking about the type of data we have. Is our data flat or does it contain nested arrays? What should happen when both arrays contain the same key?

PHP provides three ways to merge arrays.

1. The array union operator: +.
2. The array_merge function.
3. The array_merge_recursive function.

We may also need Zend\Stdlib\ArrayUtils::merge which ships as part of Zend Framework 2 and can be included in our application by requiring zendframework/zend-stdlib with Composer.

Choosing the right function

Structure

When our data is flat we can use array_merge or the + operator. When we want to merge nested arrays we must use a recursive function like array_merge_recursive or ArrayUtils::merge.

Duplicates

Duplicates occur when both input arrays contain the same key. Only keys are considered when determining duplicates, not values. Duplicates create a merge conflict that is resolved by either appending or replacing duplicate key values.

Only the + operator behaves consistently (it always replaces duplicates); the other merge functions change behaviour depending on whether the key type is numeric or a string as shown below. However, ArrayUtils::merge will behave consistently when true is passed as the third parameter since Zend Framework 2.2.6.

Numeric keys

With the exception of the + operator, values in numeric keys are appended and reindexed. The + operator always replaces duplicate keys regardless of the type.

Examples

In these examples both arrays have the same implicit numeric key (0). The + operator drops duplicates found in the right operand.

[1] + [2];

[0 => 1]

The merge functions append values and reindex keys. Since the input arrays are flat in these examples, the result is the same for the recursive functions.

array_merge([1], [2]);

[0 => 1, 1 => 2]

String keys

With the exception of array_merge_recursive, values in duplicate string keys are replaced. However, array_merge_recursive always appends duplicate keys regardless of the type.

Examples

Like numeric keys, the + operator always drops duplicates found in the right operand.

['foo' => 1] + ['foo' => 2];

['foo' => 1]

For string keys, array_merge drops duplicates found in the first argument.

array_merge(['foo' => 1], ['foo' => 2]);

['foo' => 2]

array_merge_recursive preserves duplicates by pushing each value into a new array under the duplicate key.

array_merge_recursive(['foo' => 1], ['foo' => 2]);

['foo' => [0 => 1, 1 => 2]]

Precedence

The argument for which duplicate keys are kept is said to have precedence during a merge. Argument order determines which values are kept and which are lost during replacement.

The + operator gives precedence to the first operand but the other merge functions give precedence to the second argument as shown in the table below. Argument order for array_merge_recursive is usually irrelevant since it always appends duplicates.

Conclusion

To merge two arrays correctly we must consider the data structure of each array and how we want to handle conflicts that occur when both arrays contain the same key. Once we know the data structure and have chosen a duplicate handling strategy we can select the correct function to merge our arrays.

Finally we ensure our arguments are specified in the correct order to give precedence to the array whose data we wish to keep when conflicts occur.