[geocar]

> Imagine if you used a library with a function called sortAlphabetically that didn't sort items alphabetically, it wouldn't make sense.

And imagine if it used [binarySearch](http://googleresearch.blogspot.co.uk/2006/06/extra-extra-rea...) as part of it's implementation? Then `sortAlphabetically` would be broken, and people might waste a lot of energy looking everywhere else instead of just looking at the data and reading the code.

> Imagine a situation where a bunch of constants for an API are defined as such:

Are really all of those definitions helpful?

If I want to search for `/getUser` in a program, I might do `grep -r getUser .` and then learn that I need to repeat that with `grep -r kURLAPIGetUser .` -- was that really better?

If `/getUser` is being used in more than one place, then maybe we should talk about that problem of duplicating effort. If it isn't, then the define is absolutely worthless.

[Dylan16807]

This is such a subtle problem that countless people implementing binary searches didn't think about it, yet you think reading an unlabeled blob of code will make people notice?

[geocar]

Yes, I think if programmers do not actually read code, they will not notice the bugs in it.

Considering the binary search more deeply, http://comjnl.oxfordjournals.org/content/26/2/154.full.pdf is useful; De Angelos search (family 4) was a successful search, but it contains this bug. Implementations based on families 1 and 2 but perhaps trying to be less clever would not.

[Dylan16807]

That's not what I asked. Do you think they will find the bugs just because of rereading a standard algorithm?

Having to reread code when trying to accomplish something unrelated seems like a terrible way to seek out bugs.