8.2 Notation

In this book, we try to keep notation as consistent as possible. This makes reading and writing code easier. We can define the notation into three parts.

8.2.1 Julia Style Guide

Firstly, we attempt to stick to the conventions from the Julia Style Guide. Most importantly, we write functions not scripts (see also Section 1.2). Furthermore, we use naming conventions consistent with Julia base/, meaning:

Also, we avoid brackets in conditionals, that is, we write if a == b instead of if (a == b) and use 4 spaces per indentation level.

8.2.2 BlueStyle

The Blue Style Guide adds multiple conventions on top of the default Julia Style Guide. Some of these rules might sound pedantic, but we found that they make the code more readable.

From the style guide, we attempt to adhere specifically to:

8.2.3 Our additions Loading of symbols

Prefer to load symbols explicitly, that is, prefer using A: foo over using A when not using the REPL (see also, JuMP Style Guide, 2021). In this context, a symbol means an identifier to an object. For example, even if it doesn’t look like it normally, internally DataFrame, π and CSV are all symbols. We notice this when we use an introspective method from Julia such as isdefined:

isdefined(Main, :π)


Next to being explicit when using using, also prefer using A: foo over import A: foo because the latter makes it easy to accidentally extend foo. Note that this isn’t just advice for Julia: implicit loading of symbols via from <module> import * is also discouraged in Python (van Rossum et al., 2001).

The reason why being explicit is important is related to semantic versioning. With semantic versioning (http://semver.org), the version number is related to whether a package is so-called breaking or not. For example, a non-breaking update for package A is when the package goes from version 0.2.2 to 0.2.3. With such a non-breaking version update, you don’t need to worry that your package will break, that is, throw an error or change behavior. If package A goes from 0.2 to 1.0, then that’s a breaking update and you can expect that you need some changes in your package to make A work again. However, exporting extra symbols is considered a non-breaking change. So, with implicit loading of symbols, non-breaking changes can break your package. That’s why it’s good practice to explicitly load symbols.

Support this project
CC BY-NC-SA 4.0 Jose Storopoli, Rik Huijzer, Lazaro Alonso