[ENH] String>>findBetweenSubStrs: comment (was Re: [ADDITION] String
>> subStrings:)
Doug Way
dway at riskmetrics.com
Thu Nov 16 17:48:24 UTC 2000
"Richard A. O'Keefe" wrote:
>
> Doug Way <dway at riskmetrics.com> wrote:
> It hadn't even occured to me that either method would accept a
> collection of strings. In my defense, the comment for
> findBetweenSubStrs: is very unclear about what exactly is expected as a
> parameter.
>
> The method comment says
>
> findBetweenSubStrs: delimiters
> "Answer the collection of tokens that result from parsing self.
> Tokens are separated by substrings,
> as listed in the Array delimiters."
>
> It looks very much as though it wants an Array of strings, no?
> That certainly won't mislead, because an Array of strings works.
> There's a bunch of methods in Squeak's String class that take the
> same kind of parameter.
Alright, in retrospect it's not really misleading, but it still wasn't clear enough to make it obvious what it was expecting at first glance. (At least I didn't figure it out the first time. :) ) Part of the problem is that it does accept a single string as an argument, which threw me off. Somehow I assumed the "SubStrs" in the method name referred to the returned substrings, not the delimiters. (kind of like the asArrayOfSubstrings VSE method that Chris was talking about)
I still think my comment clarification would help. (okay, maybe it should say it expects a "collection of Strings and/or Characters".)
> Look in
>
> skipAnySubStr: delimiters startingAt: start
> "Answer the index of the last character within the receiver,
> starting at start, that does NOT match one of the delimiters.
> delimiters is a (sic!) Array of substrings (Characters also
> allowed). If the receiver is all delimiters, answer size + 1."
>
> In fact *this* comment is not unclear, it's wrong. It doesn't answer
> the index of the *last* non-delimiter character, it answers the index
> of the *first* such character.
True. Travis had a good point here... comments that are too detailed and start to look like code (e.g. "answer size + 1") are redundant and more likely to become incorrect as time passes, and are often worse than no comments at all. Keep comments simple and high-level, and only when really needed.
> It looks as though the method comments for all these methods could do with
> overhauling.
Yes.
- Doug Way
dway at riskmetrics.com
More information about the Squeak-dev
mailing list
|