I recently ran into a problem where an input constraint wasn't specified and I wrote my code to be resistant to invalid or incomplete input data as one should when writing an implementation of an algorithm.

When I later compared what I wrote to those who posted in the discussion I realized that many of the most concise solutions had assumed that the input would "make sense" for the problem and so their code would either produce bad answers or generate an error/exception if run on inputs that didn't match.

Many of the problems will go out of their way to specify explicit ranges for the input data, including the lengths of arrays, whether they can be null, whether the complicated manipulations will always be valid (i.e. "you will always find at least one such solution"). That is fine with respect to the purpose of a site like this where the person proposing the problem simply wants people to think about the flow of the algorithm and not be bothered by having to check for bad input, and so if the problem specifies ranges and properties of the input data that alleviates the need to check the inputs, I think that's fine.

And sometimes problems will include test cases that have unexpected nulls, arrays of the wrong size, or requests that can't be completed for a variety of reasons and your code is expected to detect the impossibility or the invalidity of the data and return appropriately. If you fail to write a solution that deals with that invalid input then you accumulate a "Wrong Answer" or "Runtime Error" result which detracts from your long-term success rate.

But, sometimes problems fail to specify a constraint on the input, but also fail to provide any test cases that check the solutions to see if they behave predictably in the face of such invalid input. Does one spend time (some would call it wasted time) to code defensively against those conditions? Or does one ignore them and assume valid inputs and potentially get an accepted solution faster, but at the risk of getting a Wrong Answer?

This is more of an issue during a contest where defensive coding might cost valuable time, but failing to do it costs a 5 minute penalty and possibly rewards the gamblers who simply ignored the potential for bad input and got their answer in faster with no penalties.

Does this matter in the bigger picture?

I think it does. In the long run, sites like this are training programmers to do a better job in the industry and so responsibility to the habits and practices that are taught here by participation should be well considered. Failing to account for bad input data not only leads to bugs that can annoy customers or cost extra time during the testing phase if the tests used are smart enough to catch it, but they are also one of the leading causes of security vulnerabilities.

I'm not saying that all problems should be specified with few constraints and a lot of tests to trip up potential solutions, but at least be consistent in specifying input constraints and testing for errors when a constraint is left unspecified.

And we should also acknowledge that writing code that naturally produces the expected result when the input data is bad without having to add additional tests for such data are more elegant than either code that sprinkles in lots of extra tests or code that is vulnerable. I'd like to see more problems including looser constraints when there is a possibility to build naturally resistant solutions - to reward/teach this additional "art of the algorithm"...