>>Length? MarkToDispatch() then? Triage()?
>>
>>Generally, I think we're better off, coming from verb-oriented languages, and thinking in verbs (and DoNoun() is not a verb, IMO). My general rule is that a method should do something, so its name should be a verb (in imperative, at least was in Serbian, where it was morphologically different from infinitive), possibly a verb plus object - .Refresh() or .RefreshPillows(). Another rule is that if I can't come up with a good name as an answer to "what does this method do? - it ~~~s", then my design is unfinished, I still don't know what I'm doing, and it's probably too early to write code. Rethink the design.
>
>Sometimes it's just hard to find a right word. Say, we have another process when we want to assign a record some mark indicating that this record has better probability of being successful and should have been worked first. The question is - how should we name this flag and the process? Currently we're using set priorities, but it doesn't reflect the exact idea.

ImproveChances()? MarkProbable()?

I love this kind of exercise - it forces you to drill down to the substance of the process you're shaping, to go beyond the form and dig into the essentials. In the end not only you know exactly what you're doing, but your methods have a reasonable, easy to read and remember, names, layout and logic.

While I was writing this, I remembered a case where I had a cascading series of SQL calls, doing a prioritized series of searches (by exact code first, then if not found by begins-with, then by name-begins-with, then by name-contains) stopping as soon as one returned some result. In the end it looked like this:

lRet=.t.
do case
   case .TryExactCode(tcString)
   case .TryCode(tcString)
   case .TryName(tcString)
   case .TryNameContains(tcString)
   otherwise
      lRet=.f.
endcase
return lRet

I had no luck with naming them until I realized each one of them was only an attempt - not even looking for a particular record, but trying to present the user with a recordset where what they're looking for may be. So, TRYxxx(). Then it started making sense. Now, four years later, it's still easy to revisit that code whenever needed.