# Gadget Developer Guide - Style Guide

If you intend to submit your new Woopsi developments back into the main source tree, you should follow this style guide. I will reformat exceptional submissions that do not follow this style before including them. Other submissions that do not follow this style will be rejected. You may not agree with the style I have adopted (and you're welcome to let me know how I can improve it in future projects), but this project's style is set in stone.

If you are not intending to share your work, I'd strongly suggest that you still follow the style guide - internal consistency is very important.

## Naming Conventions

- Variable names should be in lowerCamelCase, eg:

      u8 windowNumber;

- Class variables should be prefixed with an underscore, eg:

      u8 _width;

- Class names should be in UpperCamelCase, eg:

      class WindowBorder

- Class names should not have a distinguishing prefix or suffix
- Pointer names should not have a distinguishing prefix or suffix
- Function names should be in lowerCamelCase, eg:

      void doSomeStuff();

- Function names should start with a verb
- Do not use hungarian notation
- Enum names should be in UpperCamelCase, eg:

      enum OutlineType { };

- Enum items should be in UPPER_CASE, with words separated by underscores. The name should begin with a word that associates it wirh the name of the enum, eg:

      enum OutlineType {
      	OUTLINE_CLICK_DEPENDENT = 0,
      	OUTLINE_OUT = 1,
      	OUTLINE_IN = 2
      };

- Preprocessor guards should be in the format "_CLASSNAME_H_"; include extra underscores within the classname if appropriate
- Use short variable names(i, j, k, etc) for iterator variables, eg:

      for (u8 j = 0; j < 10; j++) { }

- Ensure that your spelling is correct

## Formatting

- Use tabs to indent - one tab per indentation level
- Split classes into .h and .cpp files
- Opening braces for functions/namespaces/classes/etc should be on the same line as the function name, eg:

       void myFunction() {

- There should be a single space between program control commands (such as "if", "switch", "while", "for", etc) and their arguments, eg:

      while (0) { }
      switch (myValue) { }
      if (false) { }
      for (u8 i = 0; i < 10; i++) { }

- There should not be a space between a function call and its parameters, eg:

      doSomething(withThisValue);

- Operators should have a leading space and a trailing space, eg:

      i = 0
      j > 3
      k < 4 : k = 4 ? k = 5

- Pointer/reference declarations should have the pointer/reference symbol next to the type, not the variable name:

      char* myChar;

      EventArgs& e;

- There is no requirement for lines to be shorter than 80 characters; if you must split lines for the sake of readability, choose a sensible split point and indent after the split

## Structure

- Use getters and setters instead of public class variables
- All code should be within classes, not global variables/functions

## Coding

It is important to remember that the DS is an embedded system. You cannot follow the same approach to coding for the DS that you take for coding desktop applications. With that in mind:

- Never use floats
- Never use RTTI
- Never use exceptions
- Never use the STL

I recommend looking through the existing sourcecode and following the standards laid out there.