What is the basic structure of a Julia Program?

I am new to Julia language but i need to know the basic structure of a Julia Program?
I asked in stack-overflow but they are not sure.
in c and java they have but in Julia I didn’t find and I search a lot

1 Like

Julia doesn’t impose much in the way of structure for programs to run; for instance you can write

println("Hello World")

and save it in a file called test.jl. You can then run it by calling julia test.jl in the command line and it will print out as expected.


Reference: https://stackoverflow.com/questions/58646668/what-is-the-basic-structure-of-a-julia-program

The original question was I believe https://stackoverflow.com/questions/58645164/what-is-the-basic-structure-of-julia, now deleted?

For more efficient and maintainable programs though, it is best to encapsulate program behaviour inside functions which you call - for instance you could emulate a typical C-like format by doing something like the following

function f(x,y)
   return x+y

function main()
    x = 2
    y = 3


Building on jbmuir’s answer, I usually define a top-level file that calls packages and my own custom code. For example,

using some_package, another_package
#A file with functions and structs etc. 
#You can keep your code in a module
using my_module
inputs = ...
results = main(inputs)
#some processing below
function myfunction()

In this example, there is a main file that calls packages and custom code, and you can perform some task/analysis and process the results. You can organize your supporting code into files based on function. If you find that you are reusing code a lot, it might be useful to organize it as a local package. If you go that route, l recommend looking through an established package in your area of expertise. For example, if you perform Bayesian parameter estimation, you could look at DynamicHMC.

As the others noted, there are not many constraints imposed. What is important is that your code is organized, modular and reusable. So basically just exercise good practice.

1 Like

For a newbie, the link below may also be useful. One needn’t understand or appreciate everything in the link yet but I found it useful to keep coming back to it from time to time when I was starting to experiment with Julia.




has the best explanation on why global variables are consider harmful (in Julia)

Thank you for bring it to my attention.

1 Like

Is this generally a good way to go about writing a script? My script currently looks something like this


<load files>

<do analysis using sub-functions >

<produce plots>

So the latter part I should wrap up into a main() function? Is it terrible practice not to place the sub-functions at the top, but in-line where they are used? I’m having difficulty in scrolling up every time I need to see what a function is doing.

Either this or what @Christopher_Fisher did with their include("custom_functions.jl") line. What are your thoughts now? Still doing the same thing or are there better ways of organizing code which uses functions/sub-functions on in a single script/program.

1 Like

As long as the actual heavy work is done inside functions, and those functions don’t refer to global variables, I don’t think it is necessary (performance-wise) to wrap everything in a main() function. But maybe someone will correct me on this.

In my opinion it is best practice to separate function definitions from code that does actual work as much as possible. Even better I think is to put all your functions inside a package and include tests (maybe it doesn’t always make sense for quick exploratory analysis, but at some point it is good to start organizing).
Maybe you will find DrWatson.jl useful with regards to project organization best-practices.

Probably your editor (together with a Julia plugin) has some kind of “jump to definition” functionality which allows you to jump to the function definition and back, so the actual location of the function shouldn’t be so important if you have this feature.


I agree with orialb. At the very least, it is good practice to store functions in a separate file or module and call them from a script. It reduces clutter and allows reuse of your code. I also agree that putting your functions in a package can be a good idea, especially if you use the functions across multiple projects. You can create tests and conveniently call your package without needing to specify paths. I also recommend creating project specific environments so that you can restrict your dependencies to versions known to work. If you want to update your dependencies, you can verify that new versions work. Running code months later only for it to crash is the worst.


This really depends on your personal preferences, the way you navigate code, and the code length. Julia can handle whatever you prefer.

My normal workflow is to start out with a small script, wait for it to inevitably evolve into utter chaos, make a half-hearted attempt at moving the functions to the top, then realize that I should have done a project to begin with because then I can use Revise.


The most important thing to me is using Revise.