Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

Are there any recommended ways to organize code? THe simulation project I'm working on has gotten a little unwieldy. I've read up on packages but have never used them before. It seems fairly straightforward? Right now I have all my code for this simulation in 3 cells:

Cell 1: Function definitions
Cell 2: Parameter Initializations
Cell 3: Main time stepping loop

This way of working seemed reasonable when the code was small but it has gotten unwieldy. Modifying function definitions is problematic since the variable names used in function definitions tend to be used in Cells 2 and 3, so they have to be Cleared in order to re-run the cell with the function definitions. I'm thinking I should just move the function definitions into a package? Then if I modify a function I do it in the package and just rerun the Package? If some of the arguments in the functions in the package are also used in the notebook where I'm working this won't cause any problems as the package won't know about the notebook?

share|improve this question

closed as too broad by Yves Klett, ciao, m_goldberg, Michael E2, belisarius Apr 6 '14 at 20:32

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

There is quite a bit of info on package use and design on this site. Your question seems too broad at the moment. –  Yves Klett Apr 5 '14 at 16:22
But the answer is: yes, switch to packages and to Work Bench and your life will become easier. –  Ajasja Apr 5 '14 at 18:02

2 Answers 2

Offhandedly, I would recommend using Module often. For example, look at this idiom:

Module[{localVar = 0},
  globalFunction[] := localVar++]

This is generally useful, but particularly so when the local variable is something that requires heavier computation. It allows you to create that variable only once yet still have it be local, as opposed to having to create it each time like so:

someFunction[] := Module[{heavyVar = blah}, ...]

Or letting it be global:

heavyVar = blah
someFunction[] := ...

Also remember that there essentially isn't a limit to the kind of stuff you can do. If you want, you can create a function which returns the set of functions you're using. One particular scenario I've used this for is creating an adoooorable little LIFO stack:

{push, pop} = Module[{stack = {}},
   {(AppendTo[stack, #]; #) &,
    Module[{last = stack[[-1]]},
      stack = Most[stack];
      last] &}];

You can think of this as object orientation, if you want. Here's a more overtly OO version:

obj = Module[{stack = {}, obj},
   obj["push", val_] := (AppendTo[stack, val]; val);
   obj["pop"] := Module[{last = stack[[-1]]},
     stack = Most[stack];

Again, the point is that you actually have broad architectural freedom, and it can be useful to experiment.

share|improve this answer

Package templates and explanation are laid out in Programming in Mathematica (3rd Edition) by Roman Maeder, one of the original designers of Mathematica. This book is written for Mathematica 3 but the information on package layout is still relevant and very clear.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.