[lamontcg]

And solving the actual problem would be much easier with test cases than an algorithm. This is made ever more important if the original implementation is "complex and likely to have subtle bugs" since that implies that anyone reading the comment is likely to miss 'seeing' important edge cases.

A really simple way to solve this would be to move the simplified algorithm to a test suite which iterated over some important edge conditions and validated that the simplified algorithm and the refactored code agreed. That would preserve the simplified code, but in a much more useful form where automated testing could be done against it.

[supercheetah]

That's assuming that your test cases test for all the subtle little edge cases. That's incredibly naive, and unlikely.

[zeckalpha]

No test suite is complete, however, each test is one better than none. With time, (30 years!) a test suite becomes complete enough to matter, as edge cases are accounted for in the wild.

[mootothemax]

>each test is one better than none

My experience has been the reverse: lots of ultimately pointless tests add nothing to a given codebase but maintenance costs and developer frustration.

The most successful projects I've worked on used (completely automated, no code getting pushed to staging unless the CI server says it passes) tests sparingly.

[lamontcg]

Having a single test for a subtle edge case that can be missed is better than a committer and a reviewer both missing that edge case and committing code that breaks it.

I can't fathom how anyone thinks that documenting the algorithm is better than running the algorithm. The only possible explanation that occurs to me is sociological and that when someone eventually breaks the code which was only documented, you can heap scorn on those who allowed it to be broken because they weren't as smart as you are to be able to see that edge case in hindsight.

Which I guess is 'better'. I'd prefer to have a test that fails. When code breaks an edge case that nobody thought of, I'd add that edge case to the test suite. It will never be perfect, but it will work at least some of the time.

And assuming that test suites must be perfect and complete to be useful is also incredibly naive and a sign of an immature and fairly novice developer. Test suites are always imperfect, you must always guard against them and not assume they do everything for you, and yet you need to take the time to build them and maintain them since they make your code quality better when they do catch edge conditions where you weren't smart enough to see your own bugs you were introducing.

I guess some programmers are just smart enough to never commit buggy code though and don't need them...