As a person from a joint CS/science background, I’m certainly not advocating sloppy coding practices. I think implicit expansion (and yes also lack of type safety) actually goes towards encouraging sloppy coding practices. Now instead of a self-documenting piece of code where one uses bsxfun(), if I read the line a .* b somewhere I have to wonder if it is the outer product of vectors or an element-wise product or anything goes. The best designed systems limit the amount of mistakes that humans can make, and allowing the syntax itself to be sloppy doesn’t seem very encouraging.

@DavidB if we know we are receiving vectors, and they may be oriented differently, the following would be more elegant compared to any requiring any logical branches:

dataA(:)+dataB(:);

@DavidB + @Guillaume + @TheBlackCat – if I remember correctly, my client wanted the code to continue processing only when the 2 inputs were both vectors, although possibly of different dimensionality. So, [1,2,3] should be combinable with [3;4;5] but not with [3;4] (which would error out downstream). In such cases the try-catch block gives the expected results, but a(:)+b(:) would not have.

As I said in the post, the code snippet is just a simplified version and the actual coding details don’t really matter. The important thing in my opinion is that for this specific use-case, a functional change in Matlab R2016b caused fully-legitimate code to return different results, and since the functional change was not documented as having a compatibility aspect, this caused an operational problem that was unacceptable. In this respect, it really does not matter whether the client’s code was due to bad coding or to explicit design.

@TheBlackCat From the limited information we have available we are assuming the data is a vector. If that is the case then I think something like this code snippet would work nicely and is perfectly human readable.

if isrow(a) && ~isrow(b) || iscolumn(a) && ~iscolumn(b)
    b = b';
end

It is hard to say without seeing more code. It may very well be that the data can only come in a few formats, so transposing it is the correct thing to do.

   dataA(:) + dataB(:)
  

But really, the proper alternative would have been to find out why the data does not come with the expected shape rather than take a gamble and flip it. I’m with David B, the code is a strong indication that something is very wrong in the algorithm somewhere and that one day, given some particular input, it’s going to break in even more unpleasant ways.

What would your alternative be? The equivalent one I can think of would be:

if numel(dataA)~=1 && numel(dataB)~=1 && any(size(dataA)~=size(dataB))
    dataB = dataB';
end

A more strict test would be:

if numel(dataA)~=1 && numel(dataB)~=1 && ndim(dataA)==2 && ndim(dataB)==2 && any(size(dataA)~=size(dataB)) && all(fliplr(size(dataA))==size(dataB))
    dataB = dataB';
end

So yes, probably from a code correctness standpoint you are probably right. However, from a readability and maintainability standpoint their solution is pretty elegant. Will it be slower? Yes, but in many cases not enough to make a difference. Does it have corner cases that it doesn’t handle? Yes, although those may not be relevant or may get caught later. But even without a comment I can tell in an instant what their code is doing, while it would take me some time to figure out what either of the two examples I posted did.

If you have another approach that is as simple and easy-to-read as the above case then of course I will retract that. But otherwise, the best algorithm from a CS standpoint isn’t necessarily the best approach once you have to start involving humans and want to be able to figure out what your code is doing 3 years down the road.

@David – while I fully agree with you that it’s not good coding style/practice, I’ve seen much worse client codes. Most Matlab users don’t have a degree in computer science, and sadly enough even CS grads often exhibit deplorable coding. In fact, my personal experience has been that only a minority of Matlab users have high-quality code. Most Matlab users use Matlab as an engineering tool and not as an end to itself: as long as something works, they don’t mind if it’s nice-looking – they just move on to solving the next problem. In this sense, the snippet above is beautiful in its simplicity, and to hell with the CS purists…

I had always assumed the reason MATLAB hadn’t implemented this feature over the last 15 years or so was that it was too big of a backwards-compatibility break.