11
$\begingroup$

I know this is a little opinion based, but so is Mathematica style guide and similar topics.

The issue is important so I think this topic will be beneficial for future visitors.

Q: So lowerCaseFunctionName or UpperCaseFunctionName convention for symbols exported from package for users. And why?

I was using lowerCaseCamelCase convention but Szabolcs made some valid points and now I'm not totally convinced. (still using it though)

Let me leave a link to those comments.

  • I'm still using lowerCaseCamelCase because I don't have to worry in future and push fixes which only rename conflicted symbols.

    In my case packages are quite localized but if you build e.g a package with wide applications, it may be that WRI will release something similar.

    Then I'd rather Protect all exported symbols so a user won't be able to do anything wrong, than go back to that again.

https://reference.wolfram.com/language/tutorial/DefiningVariables.html

Improve this question
$\endgroup$
2
  • $\begingroup$ There should be a checkbox on the lower right. But I'm not sure it needs to be changed to wiki. $\endgroup$ Commented Dec 17, 2015 at 15:25
  • $\begingroup$ @Szabolcs can't find that but ok, let's wait, moderators can change that if that's meant to be wiki. $\endgroup$ Commented Dec 17, 2015 at 15:26

2 Answers 2

Reset to default
8
$\begingroup$

Like Leonid, I also prefer capitalized public package symbols. He gave the argument that this is the conventional way to do it and discussed conflicts with builtins (unavoidable) vs conflicts with other packages (avoided through the use of contexts). I would like to add some additional arguments in favour of capitalized package symbols:

The reason why it is recommended to use lower-case symbols for everyday work (i.e working in Global`) is to avoid accidental conflicts with built-in symbols or package symbols. This of course only works if package symbols are all capitalized, just like builtins. Does the same argument about keeping symbols lowercase apply for packages as well, i.e. should packages try to avoid conflicts with the System` context the same way?

There's a big difference between how I write Mathematica code during everyday for or for a package that I might share with others.

Most of the code I write during normal work is written quickly, focuses on getting the task done, and eventually gets thrown away (or replaced). I want to be able to work fast and not worry about name collisions so I use only lowercase symbols.

Package code on the other hand is well thought through and is usually maintained over a long span of time. In this situation having to pay attention to avoiding conflicts with builtin symbols is not a big inconvenience. If a new version of Mathematica comes out and the package conflicts with it, I would just fix that in the next release of the package. But as Leonid said, one might as well put in some thought to at least try to avoid names which might show up in future versions. To sum up: In packages there's much less need for such a safeguard against accidental conflicts with builtins because accidents can be avoided through care. There's also no need to avoid conflicts with other packages because contexts take care of that.

Another difference between everyday code and packages is that packages are used by many people. The package users will typically not be familiar with every single function from the package, and in practice they do treat the package similarly to builtins. It will be beneficial if package symbols do look like builtins so users can just follow the usual lower-case convention and be confident that they won't accidentally conflict with some package symbol they didn't even know about.

Most of what I said here applies to polished packages which might be shared with a large audience. I do not follow the same capitalization guideline for every single .m file I write and use privately, only for packages which were planned as packages from the beginning and which are relatively well thought through.

Improve this answer
$\endgroup$
9
$\begingroup$

I personally use capitalized names for exported symbols, and think that this is the recommended practice generally (for example, Roman Maeder suggests this convention in his book, which is, while dated, still probably the best reference for package writing).

The reason for that is that one wants for the exported functions to look and feel as close to built-in functions as possible.

The mechanism to avoid clashes with built-ins is of course contexts and packages. Having similar names is only a problem when two contexts are on the $ContextPath at the same time, which in most cases can be resolved, in one way of the other, by the client of your package.

There is of course one case that stands out - the System` context, since it is always present on the $ContextPath. One way to decrease the probability of a clash with some future built-in function would be to name your exported function in some unique way, in particular add some unique prefix, like

KUBAFunction1, KUBAFunction2, ...

That would at the same time mnemonically identify that a function belongs to a functionality related to a given package, and reduce the chances of clashes.

Having longer descriptive names also helps, since that also makes it less likely to collide with some future built-in.

My two cents.

Improve this answer
$\endgroup$
5
  • 2
    $\begingroup$ Upper case seems more professional but UPPERFunction1 doesn't look nice IMO :) $\endgroup$ Commented Dec 17, 2015 at 15:29
  • 2
    $\begingroup$ @Kuba Doesn't have to all be uppercase :) $\endgroup$ Commented Dec 17, 2015 at 15:31
  • $\begingroup$ TriangeLink and TetGenLink (builtin packages) use such a prefix. It's not all capitalized. I use the (admittedly ugly) IG prefix for IGraph/M because of the high risk of collision with built-in graph-handling functions. Many of the functions in IGraph/M do the same thing as builtin Mathematica functions, with small differences (e.g. one might support weighed graphs, the other doesn't, or one might be buggy and the other not, or not in the same way :P) $\endgroup$ Commented Dec 17, 2015 at 15:34
  • $\begingroup$ @LeonidShifrin that was a fantastic argument for using recommended naming conventions. its worth a lot more than a mere two cents. o_~ $\endgroup$ Commented Oct 23, 2020 at 12:46
  • 1
    $\begingroup$ @JulesManson Glad you found it useful ) $\endgroup$ Commented Oct 23, 2020 at 16:30

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.