DoL Core Coding Guidelines

[Aredhel]

The below guidelines apply to DOL core coding. If you are a contributor without access to the SVN repository please try to adhere to these guidelines in order to make it easier on us to implement your changes to the core - it will be more likely accepted by the team and speed up integration.

Committing to the SVN Repository

• SVN log messages have the following format: "- {0}: {1}" where 0 = ("Bugfix", "Added", "Changed", "Removed", etc.) and 1 = <what you did>.

Examples:

Code: Select all

- Bugfix: Cleaned my mess up.
- Removed: Some code that looked queer to me.

Here's how NOT to do it:

Code: Select all

bugfix - wrote more spaghetti code
-changed:nothing important
- removed: I don't know how to capitalize

Visual Studio Settings

The team agreed on using tabs instead of spaces, make sure you have the below settings:

Visual Studio 2008 Tab Settings.png (46.77 KiB) Viewed 47847 times

Text Formatting

• Aim for 80 characters/line, 100 may be acceptable in special cases, but if at all possible never go over the 100 character/line limit. Don't argue with me on this one, the decision is final.
• Avoid endless nesting of conditions and loops; if you haven't closed a code block after 5 braces have been opened, chances are you are on your way to spaghetti code.

Naming Conventions

• No abbreviations allowed in class names, except for common ones (example: "Id" for "Identification" is ok, so is "Ok", but "SoM" or "GoV" are not, use "ShadesOfMist" and "GuardOfValor", respectively, instead).
• Files are named after the class they hold, e.g. "ShadesOfMist.cs" for "class ShadesOfMist".
• Class and method names are capitalized, meaning the start of a new word is an uppercase letter, while the rest is in lowercase, examples:
  "ShadesOfMist" instead of "Shadesofmist", "TableId" instead of "TableID" and so on.
• Obvious variable and member names, even loop variables can be more descriptive than "i" and "j". CLARIFICATION: You may use these for as long as the context they're used in is SHORT. If you got loops with 10+ lines and use "i", "j" and "k" rethink your loop variable names.
• Member variables start with "m_", followed by a lowercase letter, the rest of the name works just like in the case of class and method names (capitalized, see above), example: "m_localValue".
• Member variables default to "private"; if you need them to be publicly available, use a property.
• Local variables and parameters are named exactly like member variables, except for the leading "m_", example: "localValue".

Comments

• Use comments wisely, if you need plenty of them, you might want to review your code instead and make it more self-explanatory, often dividing a long chunk of code into several well named methods will do the trick as well. No comments of the obvious, exception: <summary />.
• If you replaced functionality, do not leave commented out stuff lying around, the SVN will take care of version history for you.

.NET Caveats

• Prefer generic collections over HashTable, ArrayList and friends.
• Do not use object as keys in Dictionaries (here's why).
• Use the classes of the framework for string management: StringBuilder for long string creation, and static methods of the String classe, especially String.Format.

Miscellaneous

• One class per file, exception: Nested classes. Other exceptions can be made in certain circumstances, ask me first please.
• If you don't understand what some code does, do not remove it or face the wrath of tolakram!
• Do not use hardcoded constants, consider const definitions or properties instead.