Conventions

Rhapsodist’s source follows a HISE Script house style which you should also follow.

The purpose of a house style is to make the codebase consistent - it should look like everything was written by a single person. This makes it easier to understand, debug, and maintain.

Below is a quick reference of the most important points. For a full and detailed style guide follow the official HISE Script Coding Standards.

Namespaces

Namespaces should use PascalCase. Each namespace should be in a separate file with the same name as the namespace.

Don’t create namespaces that conflict with HISE’s built-in classes or with Rhapsodist’s namespaces. For example a namespace called Settings would trigger issues, as HISE already includes a class of the same name. Instead use something like CustomSettings.

If you want to be extra safe you could use a custom prefix for your own namespaces.

Functions

Use inline functions whenever possible. There are some situations in HISE script where they can’t be used but if they can be they should.

Function declarations should enforce Type Safety. The rare exception is when an undefined type is expected.

Functions should accept no more than five parameters. If it needs more, pass an object or an array, or consider splitting the function into multiple smaller units.

Recursion

HISE supports recursive functions but they should be used sparingly as they are often a cause of unexpected behaviour.

Variable declarations

• local inside an inline function or stock callback.
• var inside a function.
• const for fixed values, arrays, and objects declared outside any function. Favour MIDI lists over arrays for related MIDI values.
• reg for mutable, non-function-scoped namespace-level variables.
• global variables should never be used.
• Loop iterator variables need no declaration, HISE Script infers them.

Components

Components on the main interface should be added through the interface designer rather than through scripting.

When you do need references to a component in your script you should use the following format:

//! btnAction
const btnAction = Content.getComponent("btnAction");

Component references should be declared upfront in on init never within a function or callback.

Braces

Allman-style: the opening brace goes on its own line.

A single-statement if/for body is typically left unbraced on its own indented line, rather than wrapped in { }.

Naming

• PascalCase for namespaces.
• camelCase for variables, functions, and most component IDs
• Component IDs follow a type-prefix convention:

Comments

In general code should be self-documenting and the use of comments should be avoided. If a function name doesn’t adequately describe what the function does and leads you to write an explanatory comment, that’s probably a good sign that the function should be split into multiple smaller units instead.

Section dividers use a //! marker for a logical block (a component, a function group), worth following for readability in larger files, this allows for quick navigation within the HISE script editor.

When used, comments should not narrate what self-explanatory code does, instead they should be used for non-obvious why.

Source File Headers

The top of each script should include a license header. You can copy the header from one of the Rhapsodist files as a starting point.

For the purposes of documentation it can be helpful to include a short header comment near the top of each file after the license header.

The preferred format:

/*
@name: ScriptName
@purpose: Brief description of what the script provides.
@entry: create()
@usage: How the to make use of the script.
@notes: Any additional relevant information.
*/

It should be brief: enough to orient a developer or an AI system to the file’s role, without documenting the full implementation.