Coding Style

General

When editing a file, use the same style as the rest of the file.
Treat compiler warnings as errors, except on Windows. Our build will reject code that has compiler warnings in it. You can ensure you don’t have warnings by setting allow_warnings = 0 in the SCons build configuration.
Include unittests

Add a comment with copyright information to every file you add to the project. The copyright should be of the following form:

  /*
   * Copyright (c) 2012-2013 John Doe
   * Licensed under the Simplified BSD license.
   * See Documentation/Licenses/BSD-simplified.txt for more information.
   */

When in doubt, ask us

Naming

Always use full nouns/verbs as names, unless it is a widely accepted abbreviation, or unless it is a variable that represents an index or iterator. E.g. myThing, myJIDFactory, …
Type names (class, enums, …) are camel case, and start with a capital. E.g. MyClass, MyJIDFactory
Function names are camel case, and start with a lower case letter, and should be imperative. E.g. getValue, setValue. For boolean tests, use is as prefix, e.g. isValid()
Variable names are camel case, and start with a lower case letter. E.g. myVariable.
Member variables follow the same naming as variable names. Some people like to add an _ to the end of member variable names, which is ok (but not required). When editing a class, use the same convention as the rest of the member variables.
Macro names and constants are capitalized, e.g. MY_MACRO, static const int MY_CONSTANT
Source files have the extension .cpp (C++), .m (Objective-C), .mm (Objective-C++); header files have the extension .h.

Formatting

Use tabs instead of spaces. Everybody has their own preference of tab width, and tabs allow this. Don’t format code that is dependent on tab spaces.
Look throughout the source code to see which indentation style we use
Always use braces for control statements, even if the body only contains one statement. E.g.
```
  if (foo) {
    bar();
  }
```
NOT
```
  if (foo) 
    bar();
```
Namespace indentation: in .cpp files, don’t indent code inside the main namespace E.g.
```
  namespace Swift {

  JID::JID() {
    ...
  }

  }
```
This avoids needless indentation. What also usually works is:
```
  using namespace Swift;

  JID::JID() {
    ...
  }
```
For anonymous namespaces, it is ok to indent as usual:
```
  namespace {
    struct Foo {
    };
  }
```
Put the * with the type. E.g.
```
  Foo* myFoo;
```
NOT:
```
  Foo *myFoo;
```

Includes

Always use #include <...> (so not #include "...")
Include as little as possible. Use forward declarations if you don’t need the class definition
Include the header of every class you use
Never include the following headers in a header file:
- iostream
- Swiften/Base/Log.h
- Swiften/Base/foreach.h
In a .cpp file, always include the header of the file you’re declaring first. This avoids accidental hidden dependencies that aren’t included in the header.
Don’t include library headers in public header files (except for boost). If needed, use pimpl to hide the members of a class that depend on a library type. For an example, see Swiften/Parser/ExpatParser.h

Misc

Always use SWIFTEN_OVERRIDE (Swiften/Base/Override.h) when overriding virtual methods, e.g.
```
  virtual bool myOverriddenMethod() const SWIFTEN_OVERRIDE
```
Always use SWIFTEN_API (Swiften/Base/API.h) on Swiften classes, except for classes that need to remain private
Never use using namespace in headers. This pollutes the global namespace of every site that includes your header.
Never use default case statements when switching on an enum. This makes sure that we get compiler warnings whenever a value is added to an enum.
Every class with virtual methods needs to have at least one outlined virtual method. As a rule of thumb, always putting the destructor (even an empty one) in a .cpp file ensures this. (Note: not all classes currently adhere to this rule yet).
Prefer pre-increment (++i) over post-increment (i++). Post-increment can have a performance hit.
Prefer vector<> over list<>. Even when regularly inserting or removing from random places in a container, vector outperforms list (for data types that aren’t too large)
Use assert often. Don’t forget to include <cassert> if you use assert.
All parameters passed as references should be const. If you want to break this rule, please ask us first before submitting the patch.