One issue is that the test harness is probably happily supplying an infinite stream of integers, or at least more of them than are specified in the first input.
Hm. I'll put my hands up to the dups issue -- easily correct as you've done -- but this "they might supply more than they said they would" issue I do not buy.
The spec says that the first line will tell you how many number are in the file. If they supply more than that; they lied. More formally, they broke the contract of the specification. The fault is their's not mine.
Now, I know many people will take the approach that have taken, and say; "Well, we can cater for this unspecified possibility and handle it at very little extra cost, so we'll do that. It's defensive programming. It's a little extra effort now to save effort later....". And I say: "Just say no to trying 'what-if' code design".
Sure you can cater for that possible future; but what if:
How will cater for that?
How about if one of the numbers is 4e9?
Maybe we should cater for octal and hex; but what if they supply binary or base64 or ...?
Once you stop taking them at their word and catering for all the things they didn't say; or those they might have told lies about; you're on a slippery slope to a over-engineered project that gets canceled for going over budget.
Just say no to trying to predict the future.
Anyone who thinks my attitude to this is "just laziness"; read Meyer on Design by Contract.
In reply to Re^3: Sorting challenge (Insertion sort)
by BrowserUk
in thread Sorting challenge
by PerlSufi
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |