Quote:
Originally Posted by
Jotne
If there are good separators to use, do use that instead of counting characters.
Scrutinizer is the way to go.
That assertion is unjustified and may fill the OP with unwarranted confidence.
To be clear, I am not suggesting that there is something inherently wrong with Scrutinizer's code. What I am saying is that we don't have enough information to unequivocally state which approach is best.
It's easiest to demonstrate by presenting a hypothetical though very plausible scenario which does not contradict anything the OP has said in this thread:
Let's assume the following conditions are true:
1) The application which generates the data (generator) defines its format as a simple, straightforward, tab-delimited file.
2) There are no constraints on the contents of any field except that they cannot contain a tab.
3) There is some information in the second field which a second application (the consumer, i.e. a suggestion in this thread) needs to extract. This information is delimited by an "=" and a ";".
4) As is typically the case, the generator has no special knowledge of the consumer.
If the consumer uses anything but a single tab as the field separator, the door is opened for spectacular failure (hopefully it's nothing mission critical).
The generator, even if expertly coded with thorough error handling and sanity checks, will not hesitate to include a character which the consumer will treat as a non-tab field separator. To the generator, none of "ch=", ";ch", or "c<spc>h" is noteworthy. To a consumer that's in sync with the generator, also using a single tab to delimit, none of these is a problem. However, to a consumer accepting any of <spc>, <tab>, ;, and = as delimiters ... ouch!
While Scrutinizer's approach is clearly insufficiently robust for use under some circumstances, it may very well be a perfectly fine solution under others (e.g. a quick one-off script or for processing data whose fields comply with additional content restrictions). To which category the OP's situation belongs, we do not know.
Regards,
Alister
