Prev: Number output formatting was Re: First function debug help
Next: FindMaximum/NMaximize vs. Excel Solver
From: Canopus56 on 21 Jan 2010 04:54
In the VBA-Access world, there are generally accepted sets of naming conventions for functions, variables and objects, e.g. the Leszynski naming conventions for MS-Access (and MS-SQL) and the Reddick VBA (RVBA) for VBA.

Are there a similar set of generally accepted naming conventions for Mathematica scripts?

I have seen one general recommendation to use all-lower-case for functions, since Mathematica proprietary functions use initial caps.

Thanks - Kurt





From: Leonid Shifrin on 22 Jan 2010 05:38
Hi Kurt,

I am not aware of any strict set of accepted rules (on the level of
strictness of say the coding standards for Java published by Sun). Here is
how I understand the situation (disclaimer: I make no claims that the
following fully represents the currently accepted practices).

First, Mathematica is not an OO language in terms of natively supported
paradigms (OO can be implemented in Mathematica if needed but this is
probably irrelevant to your question), so there are no "objects" - just
atoms and normal expressions.

>
> I have seen one general recommendation to use all-lower-case for functions,
> since Mathematica proprietary functions use initial caps.
>

For functions, that's probably too restrictive given that Mathematica is a
functional language and an average idiomatically-written Mathematica program
is likely to contain many more functions than (global) variables. Many
(myself included) find it convenient to use the "camel" notation, like
<getAllWordsInText>. This can be partly motivated by the fact that this
notation is used by Mathematica built-ins. What matters is that the first
letter is lower-case - this is enough to guarantee that you don't collide
with a built-in.

If you write a package with a separate context however, it is typical to
start a public (meant to be exported) function with a capital letter. You
still should not use any system symbol names, unless you really want to
override those symbols. However, functions in different packages (contexts)
can have the same names,
since contexts play the same role in Mathematica as namespaces in some other
languages. Collisions of such symbols do happen and are known as shadowing,
but avoiding shadowing is anyway a responsibility of the user of your
package.

For variables, it seems a common practice to use all-lower-case names, since
there are typically not so many of them in any given function. I personally
sometimes use camel notation also for variables, but I don't know how common
this practice is.

There are a number of special symbols that have a built-in meaning and
should not be used. These include symbols like @, #, %,^, & and some others.
You can not use underscore (_) to make compound symbol names (like you can
in C), since it is used in pattern-building. You usually get warned by
syntax highlighting, and also you can use the Head[Unevaluated[[yourname]]
construct to see if your name is legitimate - for legitimate names this
should evaluate to <Symbol>:

In[1]:= Head[Unevaluated[abcde]]

Out[1]= Symbol

In[2]:= Head[Unevaluated[abc^de]]

Out[2]= Power

In[3]:= Head[Unevaluated[abc(a)de]]

Out[3]= abc

In[4]:= Head[Unevaluated[abc_de]]

Out[4]= Pattern

As you can see, only the first name is completely legitimate (of the above,
you can in principle also use abc(a)de, but not without a good reason).

It is also a good idea to avoid using the dollar sign $ in the names of
your functions and variables. It is used as a first symbol for names of
certain system parameters (such as $RecursionLimit, for instance), and it is
used internally to create local symbols (in functions like Module and
Unique, for instance). Thus, using it in your symbol names can potentially
break the scoping mechanism or override some global constant (in which case
you may not even get a warning message since global parameters typically
don't carry the Protected attribute).

Hope this helps.

Regards,
Leonid




>
> Thanks - Kurt
>
>
>
>
>
>


From: David Park on 22 Jan 2010 05:41
There aren't any restrictions other than using letters and numbers and
starting with a letter.

But for most work it is strongly recommend that you start with a small case
letter to avoid any possible conflict with present or future Mathematica
built-in names. In packages you might want to start names with caps because
users expect that. But there is a risk.

Stephen Wolfram also followed the practice of almost always using longer
descriptive names. I think that is a good idea. Nor does it introduce much
of a burden if you use the command completion feature of Mathematica. Using
longer descriptive names also reduces the chances of conflict with other
names - WRI names or other package names. They also make it easier to read
the code.


David Park
djmpark(a)comcast.net
http://home.comcast.net/~djmpark/


From: Canopus56 [mailto:canopus56(a)yahoo.com]

In the VBA-Access world, there are generally accepted sets of naming
conventions for functions, variables and objects, e.g. the Leszynski naming
conventions for MS-Access (and MS-SQL) and the Reddick VBA (RVBA) for VBA.

Are there a similar set of generally accepted naming conventions for
Mathematica scripts?

I have seen one general recommendation to use all-lower-case for functions,
since Mathematica proprietary functions use initial caps.

Thanks - Kurt







From: Canopus56 on 23 Jan 2010 07:30
> Stephen Wolfram also followed the practice of almost always using longer
> descriptive names. ... Using longer descriptive names also reduces the
> chances of conflict with other names - WRI names or other package names.

Thanks to all for the many great replies in this thread. Name conflicts really seem to be a common problem with several of the Mathematica archive packages that I've tried. Sometype of naming convention practice seems important. E.g. - the last one I tried was a package on importing triple variables for plotting:

-----------
Import["ListToArray.m"]

ListToArray::shdw: ListToArrayappears in multiple contexts {ListToArray`,Global`} definitions in context 'ListToArray' may shadow or be shadowed by other definitions. -----------

For VBA and javascript, I usually just append my initials for publically exposed packages to prevent conflicts.

Thanks, Kurt

From: Bill Rowe on 23 Jan 2010 07:32
On 1/22/10 at 5:38 AM, lshifr(a)gmail.com (Leonid Shifrin) wrote:


>>I have seen one general recommendation to use all-lower-case for
>>functions, since Mathematica proprietary functions use initial caps.

>For functions, that's probably too restrictive given that
>Mathematica is a functional language and an average
>idiomatically-written Mathematica program is likely to contain many
>more functions than (global) variables. Many (myself included) find
>it convenient to use the "camel" notation, like <getAllWordsInText>.
>This can be partly motivated by the fact that this notation is used
>by Mathematica built-ins. What matters is that the first letter is
>lower-case - this is enough to guarantee that you don't collide with
>a built-in.

What you write above is true. But I believe a more important
reason for camel case is readability of code. Contrast
alongvariablename with aLongVariableName

>For variables, it seems a common practice to use all-lower-case
>names, since there are typically not so many of them in any given
>function. I personally sometimes use camel notation also for
>variables, but I don't know how common this practice is.

My practice is similar. For short variable names that are also
local variables, I use lower case. For one line functions, the
variable name I use will most likely be a single lower case
letter. For longer names or global variables, I use camel case.


 |  Next  |  Last
Pages: 1 2
Prev: Number output formatting was Re: First function debug help
Next: FindMaximum/NMaximize vs. Excel Solver