-
Notifications
You must be signed in to change notification settings - Fork 36
Style Guide
There are three guiding principles behind our code style:
- Match the vanilla Stellaris style,
- Make code easy to understand even for team members who haven't looked at it before, and
- Avoid conflicts with other mods.
To accomplish this, we have the following style guide:
##1. Start names with mem_
Whenever you name a file, an event, a project, a string, a modifier, etc, please start the name with mem_
. This is the More Events Mod prefix, and it helps us avoid conflicts with other mods.
##2. Include a feature name in your names
If you are naming something only used by a single feature (e.g., one event chain or one crisis) then it should include your feature's name in it. The feature name is typically two words. So for example Enterprise of the Fallen events are called mem_enterprise_fallen.#
##3. Join words with underscores Do not use hyphens or CamelCaps.
##4. Give each feature its own files
Don't merge multiple features into the same file. If you have a particularly long feature, you might give it multiple files in the same directory, but this is rarely necessary. (See events\mem_science_convention_critsuccess.txt
for an example of where it is useful). This applies to all files for non-shared resources, so anomalies, events, projects, localisations, modifiers, etc all get their own file for each feature. Assets shared between events (e.g. some graphical assets) do not follow this rule (because they can't follow it).
This makes it easier to merge in only some features from a branch and makes it easier to include partially completed translations.
##5. When in doubt, follow the style of vanilla Stellaris All the coders will have read at least some vanilla Stellaris code while learning how it works. Following this model will make it easier for others to figure out what you're doing.