Should I return 'null' or an empty array?

In .NET it's better to return an empty array than null because it saves the caller having to write a null check and/or risking a NullReferenceException; you'll see this is a common pattern in the base class libraries. The only case in which you wouldn't do this is in the unlikely scenario that an empty array and null have different semantic meanings.

The official array usage guidelines state:

The general rule is that null, empty string (""), and empty (0 item) arrays should be treated the same way. Return an empty array instead of a null reference.

That said, if you're using .NET 2.0 or later, it's much better to return an IEnumerable<T> or one of its extensible derivatives such as Collection<T>, ReadOnlyCollection<T>, ICollection<T> or IList<T> (in which case I'd still tend to return an empty one instead of null). More info as to why these should be preferred can be found at Eric Lippert's blog.

I return an empty array - just seems like the right thing to do.

Your answer to this question probably greatly depends which language you are working in. In languages like C, It's not possible to return an empty array, as an array is just a pointer to some memory address where the array begins. In this case, the only option is to return a null pointer.

If you read your question closely, you will realize that you have actually already answered it yourself: you wrote "a method that should create and return an array of some sort" and not "a method that should create and maybe return an array of some sort or not".

Really, it depends on the specification. But with the way you phrased it, there's no way the method can return null. Which is the style I would prefer anyway, it just makes edge-case handling so much easier.

It really depends on what the caller wants to do with the result.

Usually I return the empty array (or Collection, in Java). That's because I'm usually going through a loop and optionally adding them to the Collection, and then returning it. Checking at the end if Collection.size() == 0 is an extra step. And then the caller needs to add an extra check to see if the result is 0 and if so, avoid iterating the Collection.

I appreciate it might be cleaner to return null, but it's easier not to unless I have a reason to.

If this is truly language independent I would return an empty array object, most containers should have a function such as IsEmpty() so the caller of the function would check if the Array IsEmpty before they do anything with it.

If this is in C++ I can see it either going to null, or if you're passed in a reference to the array then you return the array size...

I return whatever the caller expects. If the function is supposed to return "all objects for which X is true", and X is not true for any objects, I return an empty array.

if the function was not even able to perform this search for "objects for which X is true", then it failed, and has to signal that back to the caller somehow. That could be done by returning null.

Unless for some reason there is a differance in meaning in your code for a result being a null array verses a plain old blank one, I would return a blank one. This also might be a language specific thing. In some languages, you may only have one option.

I'd imagine this depends on the way that the language handles it.

In C, I pass pointers around and always include a pointer that is the size of the array. The calling function then has to provide two things: the array, and the size of the array. if the function doesn't populate the array, it just returns the same pointer back, and doesn't do anything to the array size. Usually i just re implement a vector type structure and work with that.

In perl, array size is handled implicitly, so i just return an empty array, or if an error, I modify the error code variable and return an undef.

In java, i use ArrayLists, and use the size property.

If you're lucky enough to be using C#, declare a static readonly property like this:

public static class ArrayUtil<TElement> 
{
    public static readonly Empty = new TElement[0];
}

(Is this in the BCL? Why not?)

You can now return ArrayUtil<int>.Empty or whatever. This pretty much eliminates the runtime costs of using empty array instead of null and gives the caller a simpler time than having to deal with nulls.

The answer depends on the contract between the caller and the function. If you intend to flag the array as not being valid, then null is a better way to do it than returning a zero-size array, since a zero-size array could be a valid result in some situation.

Well, it really depends about the semantic you want to give to your return.

Usually, I use pre and post conditions for nearly all my functions/methods. That means that if my method is supposed to return an array with data from a particular treatment, if this treatment fails, the object should be null and the post condition would fail.

But in your case, I assume you don't use DbC, so, if I refer only to your question:

What if the array doesn't get populated.

Then I would return null, as I supposed that someting went wrong in your phrasing.