I'm writing up my PhD thesis and I'm not sure about the inclusion of some of the code I have written. I have a number of MATLAB scripts that I have included in the Appendix. The issue is that I have further scripts that are completely identical but use different variables. So the code is the same but the variables are different. This is important in the body of the thesis as running the same code but on different varriables produces different results. Do I need to include every single version of the same script in the appendix, or should I just include one example of the script and describe the different variables in the caption? I ask as this turns 12 scripts into about 30 scripts, which seems a bit much.

  • 10
    Why does this code need to be in your document at all? Commented Mar 10 at 18:34
  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Academia Meta, or in Academia Chat. Comments continuing discussion, containing answers or speculation, or focused on best coding techniques will be removed.
    – cag51
    Commented Mar 14 at 15:44

5 Answers 5


It sounds like you should be using functions in your Matlab code. The purpose of functions is to avoid repeating code that does the same thing. (See Matlab's function documentation.)

So, if you have code that is a script that is a loop that adds a to b to equal c, you could define a function to do that loop and add operation as follows:

function c = loop_and_add_elements(a,b)
   for i=1:length(c)
     c(i) = a(i)+b(i);

You could save this function as a separate file called "loop_and_add_elements.m". If if is within Matlab's search path, you can do your repeated operations in a script as follows:

c = loop_and_add_elements(a,b);
z = loop_and_add_elements(x,y);

This way, you can avoid repeating the code structure that is in "loop_and_add_elements.m".

(In case it is not obvious, in the function example above, the loop is unnecessary; you could just write c = a +b; and get the same thing.)

  • 4
    and the fact that matlab only exports the top-most function in a file making you add a file for every little function you want to reuse makes it a sad excuse of a programming language. Because functions are the core idea of programming and the fact that this has to be explained to people using matlab just shows...
    – Felix B.
    Commented Mar 12 at 11:50
  • @FelixB. Octave is better than Matlab in that regard (and worse in others), but the fact that they haven't fixed this for so long is just sad indeed. Commented Mar 12 at 19:13
  • @FelixB. Not disagreeing with your general point, but apparently you can define multiple functions in a file by making them static methods of a common class. Should be quite similar to the modules found in other languages.
    – Stefan
    Commented Mar 12 at 19:50
  • 1
    I appreciate the response but this doesn't answer my question. The question wasn't about the correct way to write MATLAB code but about including code in an appendix.
    – ChrisD91
    Commented Mar 13 at 13:12
  • @ChrisD91 Fair point! I think it is good to include the code somehow for the purpose of reproducibility. You could put it on github, do a release, and then get a DOI from zenodo or your institution so that you can cite it in you thesis. Or, you could include it as an appendix. A github repository is probably more useful for other people, and it could also help you later when you are applying for jobs.
    – Tom F
    Commented Apr 14 at 1:44

(1) You can ask your supervisor.

(2) Chances are it won't make any difference. The people who assess your thesis are in all likelihood not interested in whether these functions are in the Appendix or not.


You can solve two problems with one action if you do the looping and functions. If only variables are different but with same code, simply create loop where your same code takes all the variables that require same chunk of code one by one while doing calculations. That will help you to save space, time, and workload.


Most likely you should not include any code in your appendix.

  • If code is vital to understand your thesis, it should be in the main body and discussed there. Usually those are short excerpts, not even fully functional programs.
    • If the critical part is the input (what you use variables for...) you should have a table indicating the different input variants. This likely needs no supportive code either, but prose describing the meaning/purpose of each variable.
  • If code is vital for reproducing your thesis, it should be in a code repository/archive and cited in your thesis. GitHub+Zenodo is a popular choice1 but there are other means and some universities offer similar services now.

Otherwise, generally if you have trouble presenting code that is a good indication that the code just is not written well. Instead of trying to cram it into your thesis, read up on basic code refactoring techniques to restructure your code into more readable and relevant pieces.

1 I may be biased here since it originated in my domain. Make sure to check with your supervisor and university; usually, the university library is responsible for scientific data/code archival.

  • 2
    I'd say a properly archived GitHub repository is almost always a good thing, but theses these days are mostly stored electronically, so having a whole bunch of code at the end in the appendices is no big deal. If that code is well commented/and or designed to be self-documenting, there is IMHO no reason not to have it in the thesis. Ideally it should be copy-pastable into files and able to run from those. Commented Mar 12 at 19:21

How I would solve it:

  1. Describe very clearly how your script depends on those variables
  2. Make a table that lists the values associated with each experiment. You can then refer to an experiment by refering to a partcular entry in the table.

Step 1. will be much easier if you have written the code in terms of functions and their arguments, which is best practice in code design anyway.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .