Services & ResourcesWolfram ForumsMathGroup Archive

[Date Index] [Thread Index] [Author Index]

Re: Function and object naming conventions

• To: mathgroup at smc.vnet.net
• Subject: [mg106739] Re: [mg106701] Function and object naming conventions
• From: Leonid Shifrin <lshifr at gmail.com>
• Date: Fri, 22 Jan 2010 05:38:49 -0500 (EST)
• References: <201001210954.EAA16484@smc.vnet.net>

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@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@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
>
>
>
>
>
>

• References:
  • Function and object naming conventions
    • From: Canopus56 <canopus56@yahoo.com>