Coding conventions

From ENIGMA

Jump to: navigation, search

We are not particularly picky about what your code looks like in terms of indentation, but we have outlined a few guidelines that can be followed. This is not a comprehensive list, but a general list of namespaces which seem to run together or are otherwise not obvious.

Contents

Syntax

Traditionally, we use two spaces for indentation because this makes it easier to not screw up the formatting when someone opens it on another platform. I do not use braces unless required, and I place braces on their own unindented lines unless the code in the braces is three lines or fewer, in which case I put the opening brace after the if(), or other statement. Everyone else does the exact opposite of this, so pick your own style and you'll fit right in. You should also enable word wrapping in your text editor at 80 characters.

Legalese

The importance of maintaining proper copyright headings can not be stressed enough. When modifying source code by a substantial amount (if you are not sure what amount is deemed substantial, ask us) please remember to include yourself in the copyright header. If the year is different than previous years include yourself on a new line. If you are already located on the copyright header, please remember to update the most recent year timeframe.

Types

What we are concerned about and have been seeing happen a lot, lately, are function and variable type confusion. I'll be succinct, and use bullet points.

Naming convention

Another point is naming convention. I am not the underscore-case nazi. I don't care what you name your own variables. Our current convention is snake_case for basically everything. This is violated on arbitrary occasion without repercussion. However, we are running a user-friendly API here, and in user space, functions are expected to use a consistent convention.

This convention is, again, snake case, with functions partitioned using C namespaces.

draw_ This is where primarily 2-Dimensional, but also dimensionality-insensitive drawing functions go.
d3d_ This is where functions that specifically concern drawing in 3D go. Some of these functions are renamed versions of functions from draw_, offered for the convenience of users searching for functions.
sound_ This is where functions go which concern sound resources. There are functions to play sounds and stop sounds from playing by resource ID, but the idea is that functions here specifically concern tangible sound resources.
audio_ This is where all other manner of audio functions go, as related to working with channels and playing instances of sounds.
display_ This is where you will find functions concerning the entire desktop's display, which may contain many windows not related to your program.
window_ This is where you will find functions that concern the window, as managed by the window server, desktop environment, and generically, the window manager.
screen_ This is where you will find functions that concern your program's drawing screen; that is, the region inside the window to which your program renders.
instance_ These functions concern object instances in general. Finding instances, iterating instances, creating and destroying instances.
collision_ These functions concern testing for collisions with instances. They work with not only a position for instances, but also a physical shape. They do not, in general, incorporate dynamics.

Namespaces

Functions, classes, and everything that the user is not expected to use directly should be namespace enigma, while all GML/EDL functions should be namespace enigma_user

Personal tools
Namespaces
Variants
Actions
Navigation
ENIGMA
Other
Toolbox