Scripting style: Verbs in function names

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Scripting style: Verbs in function names

Monte Goulding-2
Hi LiveCoders

In a PR I have open Peter has asked me to `Please name this function with a verb` and I recognised that in LiveCode this is something I don’t do out of habit while in other languages it is. Why? Because in the context the a function is used there is already a verb in the statement in our language. I definitely think verbs should be used for custom handler names though. It seems to me that if my gut feeling and what I’ve been practicing for a long time is seen as general best practice for the community then it should be documented.

I notice that there’s a mix of noun and verb engine functions.

What do people think:

put GetSomething() into container

or

put Something() into container

BTW I’m happy to change my ways I’m just curious what people think.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

mwieder
When I'm creating commands I make it a verb.
Or at least as verbish as possible.

When I'm creating functions I'm inconsistent.
The more common function usage is not as a verb:

put ThePartNumberOf(someText) into tLine

but I also do things like

put Tag.Italicize(someText) into tItalicizedText
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

J. Landman Gay
In reply to this post by Monte Goulding-2
All the "native" LC functions are nouns. The reason is that LC functions
can be used with either parentheses or preceded by "the". So we get this:

   put the date
   put the selectedChunk
   put the target

If these were verbs:

   put the getDate
   put the getSelectedChunk
   put the getTarget

which is weird.



On 11/3/16 5:16 PM, Monte Goulding wrote:

> Hi LiveCoders
>
> In a PR I have open Peter has asked me to `Please name this function
> with a verb` and I recognised that in LiveCode this is something I
> don’t do out of habit while in other languages it is. Why? Because in
> the context the a function is used there is already a verb in the
> statement in our language. I definitely think verbs should be used
> for custom handler names though. It seems to me that if my gut
> feeling and what I’ve been practicing for a long time is seen as
> general best practice for the community then it should be
> documented.
>
> I notice that there’s a mix of noun and verb engine functions.
>
> What do people think:
>
> put GetSomething() into container
>
> or
>
> put Something() into container
>
> BTW I’m happy to change my ways I’m just curious what people think.
>
> Cheers
>
> Monte _______________________________________________ use-livecode
> mailing list [hidden email] Please visit this url to
> subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Paul Dupuis
In reply to this post by Monte Goulding-2
Monte,

You might as well ask: Coke or Pepsi? or Mac or Windows? or iOS or
Android? or Burger King or McDonalds or (pick your favorite non-American
head to head competing things) :-)

And is complex because, for example, I like the looks of "put
Something() into container" in my code. However, when looking in the
dictionary or a list of my own APIs for my apps, where just the name is
listed, I like seeing the action (i.e. GetSomething()) as part of the
name as it reminds me of the intended action of the function.

On 11/3/2016 6:16 PM, Monte Goulding wrote:

> Hi LiveCoders
>
> In a PR I have open Peter has asked me to `Please name this function with a verb` and I recognised that in LiveCode this is something I don’t do out of habit while in other languages it is. Why? Because in the context the a function is used there is already a verb in the statement in our language. I definitely think verbs should be used for custom handler names though. It seems to me that if my gut feeling and what I’ve been practicing for a long time is seen as general best practice for the community then it should be documented.
>
> I notice that there’s a mix of noun and verb engine functions.
>
> What do people think:
>
> put GetSomething() into container
>
> or
>
> put Something() into container
>
> BTW I’m happy to change my ways I’m just curious what people think.
>
> Cheers
>
> Monte
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Devin Asay
In reply to this post by Monte Goulding-2

> On Nov 3, 2016, at 4:16 PM, Monte Goulding <[hidden email]> wrote:
>
> Hi LiveCoders
>
> In a PR I have open Peter has asked me to `Please name this function with a verb` and I recognised that in LiveCode this is something I don’t do out of habit while in other languages it is. Why? Because in the context the a function is used there is already a verb in the statement in our language. I definitely think verbs should be used for custom handler names though. It seems to me that if my gut feeling and what I’ve been practicing for a long time is seen as general best practice for the community then it should be documented.
>
> I notice that there’s a mix of noun and verb engine functions.
>
> What do people think:
>
> put GetSomething() into container
>
> or
>
> put Something() into container
>
> BTW I’m happy to change my ways I’m just curious what people think.

Almost all commands are imperative verbs:

go
do
set
put
import
grab
etc.

Most built-in functions tend to be nouns:

date
time
focusedObject
folders
files
functionNames

And some functions are adjectives:

random (although you could argue this is a nominalized adjective)
licensed

Some functions are even predicate phrases, camel-cased:

isNumber

And there are a few functions that are verbs:

flushEvents
getResource

I think the best function names are the ones that “read” naturally in a statement:

  put the random of 10 into myVar

  if isCorrect(fld “answer”) then…

So when I name commands I use verbs. When I name functions I tend to use nouns or predicate phrases, whatever reads like natural x-talk.

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

dunbarxx
This post was updated on .
In reply to this post by Monte Goulding-2
Monte.

I think it is more than the purely symmetrical "Coke" or Pepsi"

Functions return a value. It is far more natural for me to use a verb:

put GoOutThereAndGetAValue() ...

Though I must admit that any "subRoutine" call is asking for work to be done elsewhere, so that even a handler call is also similarly of this form:

doSomething

But the way function calls are framed begs for, demands a verb, even if handler calls kind of, ought to, do as well.

Craig




Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Phil Davis-5
In reply to this post by Devin Asay
I like Devin's reasoning on this. One of the great benefits we enjoy in
using LiveCode is the "English-like" syntax. This is one of LC's
hallmark features. As I see it, we should work to preserve it and extend
it in our naming of commands and functions.

My 2 cents' worth -
Phil Davis


On 11/3/16 4:00 PM, Devin Asay wrote:

>> On Nov 3, 2016, at 4:16 PM, Monte Goulding <[hidden email]> wrote:
>>
>> Hi LiveCoders
>>
>> In a PR I have open Peter has asked me to `Please name this function with a verb` and I recognised that in LiveCode this is something I don’t do out of habit while in other languages it is. Why? Because in the context the a function is used there is already a verb in the statement in our language. I definitely think verbs should be used for custom handler names though. It seems to me that if my gut feeling and what I’ve been practicing for a long time is seen as general best practice for the community then it should be documented.
>>
>> I notice that there’s a mix of noun and verb engine functions.
>>
>> What do people think:
>>
>> put GetSomething() into container
>>
>> or
>>
>> put Something() into container
>>
>> BTW I’m happy to change my ways I’m just curious what people think.
> Almost all commands are imperative verbs:
>
> go
> do
> set
> put
> import
> grab
> etc.
>
> Most built-in functions tend to be nouns:
>
> date
> time
> focusedObject
> folders
> files
> functionNames
>
> And some functions are adjectives:
>
> random (although you could argue this is a nominalized adjective)
> licensed
>
> Some functions are even predicate phrases, camel-cased:
>
> isNumber
>
> And there are a few functions that are verbs:
>
> flushEvents
> getResource
>
> I think the best function names are the ones that “read” naturally in a statement:
>
>    put the random of 10 into myVar
>
>    if isCorrect(fld “answer”) then…
>
> So when I name commands I use verbs. When I name functions I tend to use nouns or predicate phrases, whatever reads like natural x-talk.
>
> Devin
>
>
> Devin Asay
> Director
> Office of Digital Humanities
> Brigham Young University
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Phil Davis


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Monte Goulding-2

> On 4 Nov. 2016, at 10:21 am, Phil Davis <[hidden email]> wrote:
>
> I like Devin's reasoning on this. One of the great benefits we enjoy in using LiveCode is the "English-like" syntax. This is one of LC's hallmark features. As I see it, we should work to preserve it and extend it in our naming of commands and functions.

I can’t help wondering if there’s a general guideline we can apply here where if there’s a strong case for a verb then refactor as a command and if there isn’t then use a function and leverage the implied verb in the statement. I think there may be an exception with a function that returns a mutated form of the first parameter though (arrayEncode, baseConvert etc), however, they could have easily been commands…

Cheers

Monte


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Paul Dupuis
Of course, just to be contrary, English has lots of grammatical
inconsistencies. So if one of the goals of LiveCode script is to be
"English-like" shouldn't it have a few grammatical inconsistencies too?


On 11/3/2016 7:43 PM, Monte Goulding wrote:

>> On 4 Nov. 2016, at 10:21 am, Phil Davis <[hidden email]> wrote:
>>
>> I like Devin's reasoning on this. One of the great benefits we enjoy in using LiveCode is the "English-like" syntax. This is one of LC's hallmark features. As I see it, we should work to preserve it and extend it in our naming of commands and functions.
> I can’t help wondering if there’s a general guideline we can apply here where if there’s a strong case for a verb then refactor as a command and if there isn’t then use a function and leverage the implied verb in the statement. I think there may be an exception with a function that returns a mutated form of the first parameter though (arrayEncode, baseConvert etc), however, they could have easily been commands…
>
> Cheers
>
> Monte
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Monte Goulding-2

> On 4 Nov. 2016, at 10:55 am, Paul Dupuis <[hidden email]> wrote:
>
> Of course, just to be contrary, English has lots of grammatical
> inconsistencies. So if one of the goals of LiveCode script is to be
> "English-like" shouldn't it have a few grammatical inconsistencies too?

Well we won’t have any trouble there. We are already pretty inconsistent with this particularly in the mobile* APIs.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Richard Gaskin
In reply to this post by Monte Goulding-2
Monte Goulding wrote:

 > In a PR I have open Peter has asked me to `Please name this function
 > with a verb` and I recognised that in LiveCode this is something I
 > don’t do out of habit while in other languages it is. Why? Because in
 > the context the a function is used there is already a verb in the
 > statement in our language. I definitely think verbs should be used
 > for custom handler names though. It seems to me that if my gut
 > feeling and what I’ve been practicing for a long time is seen as
 > general best practice for the community then it should be documented.

Many languages have only functions, so to describe any action you have
no choice but to use a verb in function names.

Pascal, xTalk, and others have both commands and functions, each with
its own semantic role.

Every statement must have a command, and may also contain one or more
function calls.

Since the command is the verb, it makes sense that a function would be a
noun, a thing that the verb acts on.

When in doubt, imagine you're in a meeting with some major industry
player and you want to show off the beautiful simplicity of LiveCode's
"English-like" nature - do you really want do show this?:

   get getWindowList()

So much more elegant, so much more natural, so much more tTalk, to
simply write:

   get WindowList()


--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for Desktop, Mobile, and Web
  ____________________________________________________________
  [hidden email]        http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
hh
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

hh
In reply to this post by Monte Goulding-2
> Monte wrote:
> Peter has asked me to "Please name this function with a verb"

Perhaps he simply meant:
set property "name" of this function to "a verb"?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Monte Goulding-2

> On 4 Nov. 2016, at 12:07 pm, hh <[hidden email]> wrote:
>
>> Monte wrote:
>> Peter has asked me to "Please name this function with a verb"
>
> Perhaps he simply meant:
> set property "name" of this function to "a verb"?

No I don’t think so. This is common best practice so what’s up for discussion is whether this best practice applies to our language. It seems the general consensus is no but I’m still open to good arguments either way ;-)

I must admit I hadn’t thought about this too much before and had just gone with what felt right but it seems having a discussion of this in a style guide would be handy.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Mark Waddingham-2
In reply to this post by Monte Goulding-2
If the goal is to emulate (to some extent) the English-like nature of
script in our handler names, then I think it is instructive to look at
the syntactic forms employed in the current syntax that exists. I can
think of the following general forms:

    - properties:
        the X
        the X of Y

    - chunks (part access):
        item X of Y

    - predicates:
        X is [ not ] <something>
        there exists <something>

    - functions (in the mathematical sense):
        average(X, Y)
        sin(Z)

    - commands:
        encrypt X with Y using password Z
        import snapshot

A property is something which encapsulates a piece of state. Sometimes
they are constants; sometimes they are read-only and reflect state that
changes over time; sometimes they reflect something about the content of
something, or an attribute of something and only change when explicitly
set. Getting properties never have any side-effects; setting properties
only has side-effects within their domain of concern (whether it be a
library, or an object).

A chunk is something which allows access to a part of something. Again,
sometimes they are read-only, sometimes settable. Getting chunks never
have side-effects; setting chunks only have side-effects within their
domain of concern.

A predicate is a test which returns true or false, and is to test for a
particular condition. They never have side-effects.

A function (in the mathematical sense) takes inputs, and uses those
inputs to generate output. If we want to be completely pure, then they
should never have side-effects - they should be used for computational
devices... i.e. Things which synthesize a result based on input values
and related state.

A command is something which actually *does* something. Commands can and
do have side-effects.

I'd perhaps further suggest that evaluating functions, predicates,
chunks and properties should *not* be able to fail apart from due to
mis-use (e.g. asking for an object which doesn't exist, trying to
convert "ZOO" from base 10 to base 16). I think this is generally true
in the engine, the most prominent exception which comes to mind being
the 'url' chunk.

[ As a slight aside...

This latter sitation (functions being able to fail when it is not due to
mis-use) is why we have the odd situation with functions being able to
return two values (the result, and the actual return value). The reason
this is actually not ideal is that you can easily write code which is
not and cannot be made correct except by separating out onto multiple
lines. e.g.

   processMyTwoBitsOfData url X, url Y

Here, if fetching url X fails, then the command will receive empty, and
still get executed which is technically wrong in pretty much any
scenario (after all, one of the url's could actually be empty by intent
and so you the receiving function cannot tell the difference between a
failure in fetching one of its arguments, and the argument actually
being empty). In order to write this correctly you need to do:

   local tX, tY
   put url X into tX
   if the result is not empty then throw "fetching X failed"
   put url Y into tY
   if the result is not empty then throw "fetching Y failed"
   processMyTwoBitsOfData tX, tY

Of course, this might just suggest that the url chunk should throw an
error in the case of failure; but that then violates the principal that
things you cannot predict failure of *must* be explicitly checked for
success. Unfortunately, however, the world is not perfect. ]

In contrast, commands (as they are performing an action, rather than a
computation) can and do fail in ways you cannot predict. This is
typically indicated by returning a non-empty result; with any actual
returned value from a command being placed in it (in the case the
command didn't fail). [ Note: Script now has the ability to set either
the result or it from a command handler - by using return for value, and
return for error ].

So, if the goal is to reflect English-like ness in our library function
naming (in lieu of being able to actually define our own syntax directly
in one of the above forms) then the following seem reasonable:

    - property-like things: The<property>[Of<thing>]

    - chunk-like things: <Chunk>Of<Thing> / TheNumberOf<Chunk>sOf<Thing>

    - predicates: Is[Not]<Adjective> / ThereIs(A|An)<Noun>

    - functions: <Noun> (with potential suffixes describing inputs)

    - commands: <Verb> (with potential suffixes describing inputs)

I realize here function/command are a little too general - they are
difficult to abstract in a reasonable pattern as their naming will
largely depend on what they are doing.

The case in question was a MIME library with the following parts:

    - a function which returns the version of MIME to use in the MIME
header - MIMEVersion

    - a function which returns the mime type for a given extension -
MIMETypeForExtension

    - a function which returns the list of extensions matching a
wildcarded mime pattern - MIMETypeExtensions

    - a command which encodes the input in a MIME transfer encoding -
MIMEEncode

    - a command which creates a MIME multipart document from an array of
pieces - MIMECreateMultipartContent

    - a command which creates a MIME multipart document from a field -
MIMECreateMultipartContentFromField

    - a command which creates a MIME multipart email from a pre-encoding
multipart document and attachments - MIMECreateEmail

A naming scheme consistent with the above 'english-like' forms could be
something along these lines:

The MIMEVersion is actually a read-only property:

     syntax: the MIMEVersion

     function form: mimeTheMIMEVersion

The MIMETypeForExtension is essentially a parameterized read-only
property, or chunk:

     syntax: the MIMEType of extension <ext>

     function form: mimeTheMIMETypeOfExtension(<extension>)

The MIMETypeExtensions as currently posed is either a direct constant
lookup, or a 'map' over a list of constants. I think it is reasonable in
this case to consider a 'MIMEType' as either being a fixed string, or
wild-carded string (at least restricted wild-carded - e.g. text/* but
not t*t/plain):

     syntax: the extensions of MIMEType <mimetype>

     function form: mimeTheExtensionsOfMIMEType(<mimetype>)

THe MIMEEncode command is actually a pure function - it takes an input
and produces an output entirely based on the input, it cannot fail:

     syntax: <data> encoded for <transfer-encoding> MIME transfer

     function form: mimeEncodeForMIMETransfer(<data>,
<transfer-encoding>)

     ('for' suggested here because the transformation is *for* a purpose,
not an end state)

The MIMECreateMultipartContent is again a pure function - it encodes a
sequence of transfer-encoded parts into a multipart document:

     syntax: <parts> encoded as MIME multipart document <type> [ with
<params> ]

     function form: mimeEncodeAsMIMEMultipartDocument(<parts>,
<multi-part type>, <params>)

     ('as' suggested here because the transformation produces something
which is an end state - a multipart document)

The MIMECreateMultipartContentFromField, again a pure function - it
encodes the content of a field as a mime multipart document:

     syntax: <field chunk> encoded for MIME multipart document

     function form: mimeEncodeFieldAsMIMEMultipartDocument(<field id>)

The MIMECreateEmail is not truly a pure function as it can fail - it has
to potentially load data from files in the attachment arrays. It also
has quite a long argument list so is probably better considered a
command:

    syntax: encode <body> as MIME email with subject <subject> from
<sender> to <recipient> [cc <cc>] attaching <attachments> [ into
<container> ]

    command form: mimeEncodeAsMIMEEmail pBody, pSubject, pSender,
pRecipient, pCC, pAttachments

Are these names any better than the ones already used in the library? It
is hard to say - naming preferences are highly subjective!

However, one thing which I think is useful to consider in mind is that
difficulty in naming things can (in many cases) indicate that the design
is of the API is perhaps not quite right. I did the above reimagining of
the current names in the library without considering whether there was a
better way to 'slice and dice' the functionality. (For example, would it
be better to have the concept of a 'mime email object' which you use
setters and getters to configure?).

Just my two pence.

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Monte Goulding-2
Thanks for taking the time to write such a considered response Mark
>
> Are these names any better than the ones already used in the library? It is hard to say - naming preferences are highly subjective!
>
I like them, the only thing I’m not sure about is the multiple `mime` in each.

> Just my two pence.

Worth much more that the current face value!

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Dave Kilroy
In reply to this post by Monte Goulding-2
Thanks all, interesting discussion

There is another aspect of function/handler naming which is their names in relation to APIs - for example I might have a checkConnectivity() function in an mainstack's stack or card which calls a cgi.checkConnectivity() function in a code library called “cgi” - prepending each handler and function in the code library with “cgi” helps me keep track of what is going on and (I think) makes it easier to maintain and use across different mainstacks…

…just my two penneth…

Dave


> Thanks for taking the time to write such a considered response Mark
> >
> > Are these names any better than the ones already used in the library? It is hard to say - naming preferences are highly subjective!
> >
> I like them, the only thing I’m not sure about is the multiple `mime` in each.
>
> > Just my two pence.
>
> Worth much more that the current face value!
>
> Cheers
>
> Monte
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
"The first 90% of the task takes 90% of the time, and the last 10% takes the other 90% of the time."
Peter M. Brigham
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Keith Martin
In reply to this post by Devin Asay
On 3 Nov 2016, at 23:00, Devin Asay wrote:

> I think the best function names are the ones that “read” naturally
> in a statement

And that, in a nutshell, is one of the beautiful things about the xTalk
language(s). Natural readability is important, so wherever this makes
sense it, rather than generically verbifying, should be the guiding
principle.

k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
Technical Editor, MacUser magazine (1997-2015)
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

---
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Mike Kerner
Do they not teach sentence diagramming to geeks any more?  If you can't
diagram it, you can't use it in xtalk.  That's the rule.  Obey.

On Fri, Nov 4, 2016 at 8:27 AM, Keith Martin <[hidden email]> wrote:

> On 3 Nov 2016, at 23:00, Devin Asay wrote:
>
> I think the best function names are the ones that “read” naturally in a
>> statement
>>
>
> And that, in a nutshell, is one of the beautiful things about the xTalk
> language(s). Natural readability is important, so wherever this makes sense
> it, rather than generically verbifying, should be the guiding principle.
>
> k
>
>
> ---
>
> Keith Martin
> Senior Lecturer, LCC (University of the Arts London)
> Technical Editor, MacUser magazine (1997-2015)
> http://PanoramaPhotographer.com
> http://thatkeith.com
> +44 (0)7909541365
>
> ---
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Bob Sneidar-2
In reply to this post by Monte Goulding-2
Hmmm... interesting. Well for instance I have some contact functions and commands like addContact, updateContact, deleteContact, saveContact etc. and I use this regularly so getSomething() for my vote. The assumtion otherwise is that the value returned is the something you are trying to get. What if all you want is to know if the call succeeded or failed, and if failed, why? If the latter, then something() is itself misleading.

Bob S


> On Nov 3, 2016, at 15:16 , Monte Goulding <[hidden email]> wrote:
>
> Hi LiveCoders
>
> In a PR I have open Peter has asked me to `Please name this function with a verb` and I recognised that in LiveCode this is something I don’t do out of habit while in other languages it is. Why? Because in the context the a function is used there is already a verb in the statement in our language. I definitely think verbs should be used for custom handler names though. It seems to me that if my gut feeling and what I’ve been practicing for a long time is seen as general best practice for the community then it should be documented.
>
> I notice that there’s a mix of noun and verb engine functions.
>
> What do people think:
>
> put GetSomething() into container
>
> or
>
> put Something() into container
>
> BTW I’m happy to change my ways I’m just curious what people think.
>
> Cheers
>
> Monte
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Scripting style: Verbs in function names

Bob Sneidar-2
In reply to this post by J. Landman Gay
What is wierd is that we are calling commands and functions as though they were properties. Another layer in the onion. I think all this reveals how truely difficult it is to create an "english like" language, when English (and all languages) are so relative by nature and dependent to some degree on context, whereas a programming language simply cannot be without inspiring the kind of conversation we are having here.

Perhaps we have reached the precipice of high level languages and simply cannot go further without tumbling over the edge.

Bob S


On Nov 3, 2016, at 15:44 , J. Landman Gay <[hidden email]<mailto:[hidden email]>> wrote:

All the "native" LC functions are nouns. The reason is that LC functions can be used with either parentheses or preceded by "the". So we get this:

 put the date
 put the selectedChunk
 put the target

If these were verbs:

 put the getDate
 put the getSelectedChunk
 put the getTarget

which is weird.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12