Ever heard of that? I know that it means something about type driven design, but to me it means something much simpler.
Imagine #programming reading a config file. You could read it line by line and match each line to one of the possible config options. Or you could just go through all config options and try to find them somewhere in the file. This second approach is what I mean by "Parse, don't validate". Only read the data you need and ignore the rest.
@fell validate!
Typos are easy to make and often hard to spot.
Unrecognized options don't have to be hard errors. It really sucks when things don't work and you are given no clue why.
@fell There are definitely benefits to "parse, don't validate", especially with regards to JSON (since you can't write comments). I'll end up creating a "meta" object in my JSON to contain any kind of structure for comments.
When it comes to the benefits of "validate", that can be super useful for ensuring that the config file is setup properly. Otherwise you end up wasting time on nothing more than a misspelled word, causing the config to use a default value.
Add comment