Code Style Guide

Use The Flex Style Guide

In order to be consistent with most exiting ActionScript codebases, we use the Adobe Flex Coding Conventions. These are the core of our style guide, and the rest of this document merely notes where we differ or expand on their guidelines.

Naming

This section defines how all elements in your code should be named, as well as some special cases for specific types of classes.

Definitions

• Upper Camel Case: The first letter of every word, including the first, is capitalized.
• Lower Camel Case: The first letter of every word, with the exception of the first, is capitalized.

Abbreviations

Abbreviations should not be used. Extremely common abbreviations, such as min or max, are okay.

Acronyms

Acronyms are okay. If the acronym is treated like a word, and the first letter should be capitalized, capitalize every letter in the acronym, otherwise, leave all letters lowercase.

Component Names

All components should have the word 'Component' appended to their name.

Event Names

All events should have the word 'Event' appended to their name.

Callback Names and Event Handlers

The first word should always be 'on'.

Error Reporting

There are several different ways to indicate runtime problems with the execution of the engine. This section defines the situations in which these different methods should be used. Additionally, the errors should be dispatched at the highest possible level in the call stack. For instance, a lookup method should not report that it failed to find an object. Instead, it should return null, and leave the reporting up to the calling method.

Log Messages

These should be used to report general information about the state of the engine.

Log Warnings

These should be used to report problems that don't inhibit the engine's ability to run, but could potentially be a problem.

Log Errors

These should be used to report problems that could impact the ongoing stability of the engine.

Exceptions

These should be used in situations that cannot be recovered from.

Whitespace

• All mathematical operators (+, -, =, etc) should be surrounded by spaces.
• Parentheses do not have spaces immediately inside of them (to the right of opening parentheses, to the left of closing parentheses).
• A space should not exist between a function name and the opening parentheses.
• A space should always follow a comma or semi-colon except at the end of lines.
• A blank line should always follow a closing brace or single line block.
• Blank lines should be used to logically group sections of code.
• Ridiculously long lines should be split onto multiple lines, with subsequent lines indented two extra levels.

Braces

• A brace should always be the only character on its line.
• Opening and closing braces are at the same indent level as surrounding code, and each other.
• Every opening brace indents code by one level (3 spaces).
• One line blocks do not have braces.
• One line if statements with multiline else statements, or vice versa, do have braces.

Other

• Numbers that can be non integers should always have a decimal, even it if is just '.0'.
• Use parentheses in complex operations even if order of operations doesn't require it.
• Prefer early out returns to nested if statements. Try to minimize indentation depth
• One statement per line, in every case.

Imports

• Organize imports by library, with a blank line between libraries.
• Explicitly list imported objects, rather than using package.*