DoL Core Coding Guidelines

Dawn of Light related news and announcements.

Moderator: Developer Team

DoL Core Coding Guidelines

Postby Aredhel » Thu Jun 18, 2009 3:56 pm

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>.

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
Visual Studio 2008 Tab Settings.png (46.77 KiB) Viewed 44904 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".


  • 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.


  • 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.
User avatar
Inactive Staff Member
Posts: 1024
Joined: Sat Apr 14, 2007 1:49 pm
Location: Germany

Return to Announcements

Who is online

Users browsing this forum: No registered users and 1 guest