DevIDEDevelopers

wxDevIDE Developer guidelines

wxDevIDE is written in C++ with the wxWidgets library. Source code is to be kept in a subversion (SVN) library. Before committing changes to SVN, developers will format their code using the AStyle tool and document their code using Doyxgen. Write access to the SVN is limited to project developers.

Code

Source formatting guidelines:
Use nested indentation, tab indentation only. (this will make it very easy to reformat later without indentation errors and such)
use spaces around operators, and one space after a comment in function ()
each curly-brace on its own line. (makes finding the beginning and end of a block easy)
comments at end of a large macro block indicating the intended beginning
when declaring or prototyping a function with a large number of arguments put them on their own line and indent
no spaces between a function name and ()
* and & should be glued to the left side of the variable they modify.

the result should appear similar to this:

!/usr/bin/c
class proto : public wxControl
{
    public:
    proto(wxWindow *parent, wxWindowID id,
          wxpoint &pos = wxDefaultPosition,
          wxSize &size = wxDefaultSize,
          long style = 0,
          wxString &name = wxEmptyString);

    private:
    thing *something;
);

proto::proto(wxWindow parent, wxWindowID id,
          wxpoint pos,
          wxSize size,
          long style,
          wxString name)
:wxControl(parent, id, pos, size, style, name)
{
    if(something == other)
    {
        do something;
        something = a + b - p;
    }
    Athing *th = new Athing();

    return value;
}

A few notes, I(Nuklear) don't put spaces between () and the arguments, if you do I don't care.
I don't indent declarations after public, private, protected because they are already indented inside of the class.
If you prefer to indent again it doesn't matter there either.
I usually put an empty line between the code in a block and a return at the very end of a function for readability, that's also optional.

These guidelines can be discussed some before we get started. I have not checked Astyle out to know how close it will come to formatting this way.
I use this formatting because it is clean and easy to read, when putting the cursor next to a curly-brace the indent guide will show a straight line
between them and the nesting makes the hierarchy very clear.

Projects

I Have been working on a text editor for some time, Ive been more concerned about making it robust and work the way i want than actually getting it complete. So I've rewritten it many times and build some support modules for it. XSTC, MultiBook, SciDocManager all being a part of the general editor project. I also have some other modules planned when I get those finished and actually start building the editor. Some of those support modules will be included in the IDE.

Also PackMan 2 Extended is a C++ rewrite of the DevC++ package manager for addons. (DevPaks) wx2xml is a tool to parse wxWidgets code and produce an XRC document to represent it. (A tool to help porting wxDev-C++ projects to wxDevIDE)

As stated above the wxDevIDE project is not entirely monolithic in scope. The primary development of the IDE and Form Designer will be done on this project space. Essentially there are two parts to this project, the IDE and the Form Designer.

The [wiki:IDE IDE] is aimed to be comfortable and familiar to a Dev-C++ and wxDev-C++ user. It is not a clone however, we are adding some modern features and fixing some of the old shortcomings. wxDev-C++ has already added some of the features we want, multiple compiler support, docking.. It is missing some things still, one of the things I find myself needing more than anything else is build targets. workspaces are also missing, however I would like to make the use of workspaces optional. a project can be part of one, or it can be standalone. Unlike MS creation of a workspace file should only happen if the user created it.

The [wiki:FormDesigner Form Designer] project will mostly be a port of the one in wxDev-C++. There are a few key differences however. It is going to be a true WYSIWYG designer for wxWidgets. Also instead of built in code generation, XML templates will be used in order to easily support different versions and to make bug fixing easy. In general it could have loose support for other toolkits if someone wanted to build the templates. It wouldn't be fully supported but it could be done.

Commiting Code

Only developers have write access, clearly. Before committing to trunk your changes should be evaluated by the other project members and any problems they may introduce should be resolved. (within reason based on development stage and such) If you are working on a significant portion, you can request a branch to work freely in until you think the code is ready to be reviewed and added to trunk.

SVN is the repository we are using. In the past one of the guys that was working with the wxDev-C++ project started porting Dev to C++. This code was moved to Branch0.

the following is an old page from trac

wxdevidesm.png

Developer Guidelines for wxDevIDE

Use of Capitalization

Variables

Variables start with a lowercase e.g.
int myAge;

Objects, Stucts and Enums

Objects, Structs and enums are capitalized e.g.

class !MyClass;
struct !MyStruct;
enum !MyEnum{enum1};

Method Names

Method names are capitalized, e.g.

int !MyMethod()
{
}

Word Separation

Words will be separated using Capitalization. E.g.

MyReallyLongSeparatedWord

Indentation

Tabs are used for indentation, each level of code will be indented by one tab level. By default a tab will be set to 4 spaces wide. E.g.

int !MyFunction()
{
 if(a == b)
 {
  !YourFunction();
 }
 return 5;
}

Spacing

There will be a space between operators and operands with the exception of parenthesis and semicolons. E.g.

a = b + c - d * f / (g + e);

Developer Disputes

Although the developer teams consists of reasonable people, there are occasions when individuals have a strong difference of opinion. The teams desires to avoid situations where feelings run high and one or more developers leave with a great deal of bad feeling.

Resolving Disputes

There are two suggested routes for resolving disputes.

• Tony's proposal is that for major policy/architecture conflicts we go with a simple majority. For example if there are 5 developers then if you have 2 on your side you have the needed votes to carry your proposal. If it happens that the development team has an even number, for example six and the votes reach a tie break, then the lead developer's vote counts as two votes.

• Malcolm's proposal is that the two developers in dispute should sit down with a bottle of Southern Comfort and take turns drinking a glass, the one who remains coherent the longest wins. You can rest assured that Malcolm and I will be in dispute on many occasions. ;-)

• If you are on the losing side then you need to accept that this is the way the team has voted.