Re: "test if" vs. "determine whether" - for API function descriptions ?

[Lin Sims <ljsims -dot- ml -at- gmail -dot- com>]

Or split-p soup ...

On Tue, Jan 5, 2016 at 2:58 PM, Peter Neilson <neilson -at- windstream -dot- net>
wrote:

> Test is better than determine because the latter can mean "establish as
> true" rather than "test whether it's true".
>
> It is unfortunate that there is not a standard naming convention for the
> functions. In the very early days of lisp programming (I mean, like maybe
> 1961) it was common to end an expression with "p" if it was a true-false
> predicate. (Perhaps it still is. I don't know.) The lisp-hacker slang of
> the day included such expressions as "lunchp" which was pronounced
> lunch-pee but which meant, "Shall we go to lunch?"
>
> On Tue, 05 Jan 2016 14:37:50 -0500, Monique Semp <
> monique -dot- semp -at- earthlink -dot- net> wrote:
>
> Hello, WR-L-ers,
>>
>> For an API Reference, Iâve got lots (and lots) of descriptions for
>> functions that return TRUE or FALSE depending on whether a given
>> condition/state/whatever is true or false.
>>
>> And Iâm wondering which (brief, as in the @brief command in Doxygen)
>> descriptionâs start text might be âbetterâ, âmore quickly grokedâ, âeasier
>> for ESL readers to understandâ:
>>
>>   * Test if <condition, such as âthe object is the first in the listâ>.
>>   * Determine whether <condition, such as âthe object is the first in the
>> listâ>.
>>
>> Thereâs no consistency in the function names (and I am not about to try
>> to get the code refactored). Names might begin or include âisConditionâ,
>> âConditionâ, âcheckIfConditionâ, and so on; or they might not.
>>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Visit TechWhirl for the latest on content technology, content strategy and
> content development | http://techwhirl.com
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as ljsims -dot- ml -at- gmail -dot- com -dot- 
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
> http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications?  Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions?  Search our public
> email archives @ http://techwr-l.com/archives
>



-- 
Lin Sims
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives