I was reading Eric Lippert's blog post, and came across the following quote: "uncertainty erodes confidence in our users that we have a quality product that was designed with deep thought, implemented with care, and behaves predictably and sensibly".
How very true.
By default, the code we are developing should run in exactly the same way every time it is invoked - this is what our customers usually want. For example, in my experience every select should have an ORDER BY clause, and that clause should uniquely identify the order.
Of course, when we are determining the requirements, we always need to ask the customers how to sort the results. Suppose, however, that they tell us that they don't care about the ordering of the result set. Should we skip the ORDER BY clause and potentially save some CPU cycles on sorting?
In most cases, I would not do that, and the reason is simple: even if we explicitly say in the documentation that the sort order of the results is not guaranteed, eventually someone will rely on that order. If, no, not if, when the sort order changes, that will break something. Somebody will complain that their code is broken. Surely we can educate our customers that
Without ORDER BY, there is no default sort order
If we explain it well, they will surely understand it - they are at least as smart as we are. Yet they still may sometimes rely on that sort order, because apparently the whole concept of unordered result sets is counter-intuitive to a lot of very smart people.
So, if we do not add an ORDER BY clause in our store procedure, later on we may have to return to that procedure and add ORDER BY, regardless of what our customers are saying right now. In fact, in most cases our customers do want our code to run in exactly the same way every time it is invoked, unless they explicitly request random behavior.
Let us save everybody's time and by default add an ORDER BY clause every time we develop a select that delivers results to the client, unless there is an explicit requirement not to do so.