GUI development Guidelines¶

General Guidelines¶

Usually the testing of GUI codes is quite relaxed and there is no review process. This is for three reasons:

1. Automated testing a GUI is more complicated than testing individual modules.
2. The GUIs are just "sugar" on top of the actual analysis codes, which if everything fails, can usually still be run via the command line.
3. "Testing" is assumed to be done "during development", meaning the coder should run at least the normal stages of their GUI once before releasing it.

Model-View-Controller Architecture¶

While not strictly enforced, our GUIs follow the Model-View-Controller architecture, as it is a very useful and therefore also very common GUI pattern. A better explanation can be found here, but this section summarizes a few key points relevant to our usecase.

The main philosophy of the MVC architecture is to separate the actual GUI elments, the View, from the underlying data, stored in the Model, and let the Controller handle the communication between the two and with the user.

In our code this is not always possible or strictly enforced and sometimes it is even hard to distinguish whether something should be part of the Controller or the View, but it is a good idea to at least think about if it can be done for the specific part you are working on.

Main advantages of the MVC architecture are:

• The Model components are usually easier to test.
• It automatically reduces complexity and coupling in the GUI code, by its built-in separation of functionality and modularization.
• This makes it easier to reutilize code between different parts of the GUI (e.g. re-use of the same data) or even between different GUIs (e.g use the same plotting components).
• It is easier to find the part in the code that you want to change (i.e. do you want to make a cosmetic change? - View; or a workflow change? - Controller; or a change in how to store data? - Model).

Java Guidelines¶

While the java development is not as strictly regulated as the python repositories, this code has been used for many years and probably will be continued to be used for many years to come.

Try to keep it clean!

Because GUI testing is hard and because we have easy access to old versions via CAS, there is no tests suite and no review process for the java development and changes can be simply pushed to the master branch.

Some "best practices" have been established through the years:

• Follow the MVC architecture.
• Do not re-invent the wheel, reuse or at least orient yourself to existing code whenever possible.
• If you see horribly written code (yes, it exists /s), do not hesitate to fix it.
• Use camelCase for variable names and PascalCase for class names.
• Put all external paths as constants into the src/java/cern/lhc/betabeating/external/ExternalPathsCollection.java.
• As in python, use constants (static final String) for strings.
• If you are introducing new "properties", which can be set via the bbgui_user.properties file, use the prefix PROPERTY_ (and static final String) to make them easily searchable in the code.
• Follow the note about adding new settings.
• Do not use Strings for file paths, for now we mostly use File objects (but see also the Issue #239).