I think there are several lessons that can be learned from this article, but the one that some of the responders seem to be ignoring is that most projects are built around specs and sometimes you can't change them.

For this exercise, the specs were:

1. The string to be evaluated is a column in a table

2. The only operations we need to handle are -, +, *, / and %

3. Operations are processed from left to right, with no other precedence to be presumed.

Once this has been established, there is nothing to be gained by saying that the specs are wrong or that's not how it's done in the real world. We also can't say Ben's solution is wrong since it apparently works for him. Let's face it. In the "real" world, this is an extremely non-standard way to store data. Odds are that no one outside of Ben will ever come across this problem. And it's probably a one-time thing for Ben. But, we will each come across our own unique data problems where the techniques discussed here may be of use.

What we, as readers/kibitzers, should be doing is three-fold...

First we look at Ben's solution to see if he's used any techniques that we've not used before. If so, we want to file these away in case they might be useful for us in the future.

The second thing we should do is present alternatives, so that Ben and other readers can learn something new, while staying within the specified parameters.

The third thing that I like to consider is not that the specs are wrong, but what if they change in the future? What are the likely changes that would affect the code? Is it worth coding now to allow for these possible changes? Is your code understandable enough that someone else could make the change?

The answer to these largely involves knowing your customer base to determine what is likely, deciding how difficult it would be to implement any change.

For instance,

What if they add another operator? This is probably a simple change for one or two new operators.

What if they add an operator that is more than one character? This is a little more involved, since the initial coding probably assumed each operator was a single character.

What if they do want to implement operator precedence or include parentheses? This would be a big change and likely involve a rewrite. So, this is a possibility that should be immediately addressed and since it wasn't, we assume it's beyond the scope of this exercise.

Bottom line, I thank Ben for taking the time to write the article and I hope he (and perhaps others) find some value in my reponses.