[Crossfire-wiki] [Crossfire DokuWiki] page changed: coding_style_guide

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:

Date        : 2008/01/19 14:39
User        : kbulgrien
Edit Summary: Reduce outline depth under General so sidebar index lists all sections.

@@ -1,5 +1,5 @@
- The following is a wiki-fied reorganization of of //crossfire/doc/Developers/programming_guide// from the server source.
+ The following is a wiki-fied reorganization of //crossfire/doc/Developers/programming_guide// from the server source.
  
  ====== Currently used conventions ======
  
  =====Naming=====
@@ -52,25 +52,25 @@
  
    - Only add name options with //#ifdef'//s to the ''config'' file if the behaviour seriously changes the game.  Adding a new spell does not warrant an //#ifdef//. There are already too many options in the ''config.h'' file.
    - If you want to add special debug code for certain compiles, generate a unique //#define// for it - don't use the global DEBUG.  For example, NEWCS_DEBUG.
  
- ====General====
+ ====General Guidelines====
  
    - Try to keep lines to less than 80 columns when possible.  This is not a strict requirement - don't break up some complex comparison because the line would otherwise be 83 characters long.  Xterms can be resized to most any width.  However, use your judgment on whether breaking up a long line would make something more or less readable.
    - Write code that can easily be maintained in the future, not code that is easiest to write quickly.  In other words, do not do the quick and dirty hack, but instead always write code with maintainability and clarity in mind.
  
- ===Indentation===
+ ====Indentation====
  
    - Indentation is 4 spaces.  This can be a pain to read, but most functions should be consistent through the function.
      * While a lot of old code may use 2 spaces, a move to 4 spaces makes readability easier.
    - #if directives and friends are not indented.
  
- ===Data Types===
+ ====Data Types====
  
    - Try to use the [s/u]int[8/16/32] whenever possible.  Use the one of appropriate size/type.  If not sure, go for the next size up.  Do not ever write code assuming that any of those will have an exact number of bits - those types only mean that you will get at least that many bits - you may get more.
      * The exception to this are strings.  Continue to use //char//, since the signed-ness of functions that take string options can differ system to system, and generate excessive warnings if the wrong sign is used.
  
- ===Statements===
+ ====Statements====
  
    - As discussed on irc, the preferred style for expressions is like this:<code>
  if (expression) {
    statement;
@@ -92,9 +92,9 @@
      * No space before the right parenthesis
      * Comma right after the formal parameters
      * Space after the commas.  
  
- ===Comments===
+ ====Comments====
  
    - When adding new function, include a comment of what the function is supposed to do, what options it takes, and what if any value it returns. This makes debugging of such functions easier, and also makes it better known to other developers if that function might be useful to them.
    - Do not use C++ style comments (%%//%%).
    - Functions are documented like this.<code>/**


IP-Address  : 70.254.39.97
Old Revision: http://wiki.metalforge.net/doku.php/coding_style_guide?rev=1200774853
New Revision: http://wiki.metalforge.net/doku.php/coding_style_guide

-- 
This mail was generated by DokuWiki at
http://wiki.metalforge.net/