Most of my colleagues seem to think otherwise. The pre-sales and non development colleagues are unaware of this and other developers(90% are senior to me) seem to think it doesn't matter as the users don't really care.
Problem: Whilst implementing a new feature where we accept a setting file in form of JSON, the specification does not specify which types the values are. On the surface this isn't such a big deal as it's very obvious to deduce the types: thickness, transparency, etc are obviously numbers, others are obviously strings. But after implementing the feature, the colleague mentioned that I should take all values as string first, then attempt to parse it to double because many users don't know the difference.
He's correct in a sense that his method seems more "defensive" and the specification does not explicitly specify the types of the values. But I am somewhat hesitant because I think we are actively encouraging a bad practice.
So what should I do? Ask the designer to explicitly specify the types on the specs sheet? Change my implementation to take it as a string? Or leave it as it is and display error when incorrect type is given for the value?
UPDATE: What ended up happening is we decided to use a common logic which accepts the strings as well. I told my team manager that the types were missing from the specs and he said he will talk to the designer.