Changes between Initial Version and Version 1 of DevelopmentGuidelines


Ignore:
Timestamp:
Sep 4, 2007 10:35:33 AM (7 years ago)
Author:
tim
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DevelopmentGuidelines

    v1 v1  
     1= Development Guidelines = 
     2 
     3Whilst these guidelines are not compulsory for PC-BSD development, following them will help other developers get their head around your work, and help you to get your head around theirs. 
     4 
     5== Coding Style == 
     6 
     7=== Naming Conventions === 
     8 
     9All names should reflect in some way, what it is they are labelling. A method which gets user details for example, might be called getUserDetails(). However, different capitalisation rules apply. 
     10 
     11 * Class names should be in CamelCase with the initial character capitalised. UserDescription for example. 
     12 * Method names should also be in CamelCase, with the initial character in lower case. getUserDescription() for example. 
     13 
     14=== Indentation and Parenthesis === 
     15 
     16Each layer of indentation should be one tab (3 spaces) deep. 
     17 
     18Parenthesis should be placed on their own line, at a level of indentation one above the enclosed code. If the enclosed code is only one line long, forgo the use of parenthesis altogether and keep everything on one line. 
     19 
     20{{{ 
     21#!cpp 
     22void exampleMethod() 
     23{ 
     24        anotherMethod(); 
     25        if (something) doSomething(); 
     26        else 
     27        { 
     28                dontDoSomething(); 
     29                doSomethingElse(); 
     30        } 
     31} 
     32}}} 
     33 
     34=== Spacing === 
     35 
     36A single space should be used to separate arguments. 
     37A single space should be placed either side of an operator, unless that operator has only one operand, ++ for example. 
     38 
     39{{{ 
     40#!cpp 
     41for (int i = 1; i < 10; i++) 
     42}}} 
     43 
     44== Internationalisation Support == 
     45 
     46All strings in forms, will automatically be subject to extraction and replacement via our translation tools. However, developers need to flag strings within source code as translatable. This applies to any string the user is ever likely to see in the application, except debug messages sent to the CLI via qDebug(). 
     47 
     48To mark a string as translatable simply enclose it within the tr() method. For example: 
     49 
     50“Unknown Setting” becomes tr(“Unknown Setting”) 
     51 
     52== Documentation == 
     53 
     54Developer documentation for your application should be placed into the development wiki. Each application should have a page of its own, and the page name should be equal to the subversion module name. To create a new page, simply visit trac.pcbsd.org/wiki/moduleName, trac.pcbsd.org/wiki/kcmPBSystem for example. If the page doesn't exist already, and you're logged in with wiki editing permissions, you'll be presented with the option to create the page. 
     55 
     56You should provide the following information, as a minimum, for your application: 
     57 
     58 1. The name of your application, and its intended purpose. 
     59 1. A list of all the source files in your application, with a brief description of their role. 
     60 1. A list of any external applications used, along with how and why they are used. 
     61 1. A list of any external libraries used, with a brief description of what they're used for in your application. 
     62 1. A list of configuration files your application uses, and what it stores in them. 
     63 1. A list of registry entries you application reads and writes to, along with what is stored within them. 
     64 
     65Any diagrams you can provide, UML or otherwise, should be included, but are not required. 
     66 
     67== Licensing == 
     68 
     69All code written for PC-BSD, should be BSD licensed.