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>

**Re: Re: simple nest**

**Re: What is the difference Between MakeBoxes and ToBoxes**

**Function and object naming conventions**

**Re: Function and object naming conventions**