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