On this page... (hide)

Beautifying

All your code should be beautified with clang-format using this .clang-format file. This file is already part of CodeLite's git repo, so you should have it in your root folder of your CodeLite sources.

Configure CodeLite to use clang-format, from Plugins->Source Code Formatter->Options->General->C++ formatter and select clang-format
Configure clang-format from within CodeLite to read its settings from CodeLite's .clang-format file. Plugins->Source Code Formatter->Options->C++->clang-foramt->Style and set it to File

General guides

CodeLite is an open source cross platform IDE; as such, you should avoid using platform-specific calls. If you can't find a cross-platform replacement for the call you need, make sure that the call is wrapped with the proper #if/def block:


#ifdef __WXMSW__
    // Windows

#elif defined( __WXGTK__)
    // Linux / FreeBSD

#elif defined( __WXMAC__ )
    // Mac OSX

#else
    // Unknown OS

#endif

CodeLite uses the wxWidgets toolkit; this means that you should prefer wxWidgets library calls over any other library. For example if you need a regular expression, even if you have good boost::regex knowledge you should still prefer wxRegEx instead of boost::regex.
Namespaces - CodeLite does not use namespaces, so try to avoid placing your code inside namespaces.
STL namespaces - CodeLite makes use of all STL containers. Always prefer an STL container over anything else (e.g. std::map, not wxHashMap).
Do not use using namespace keywords; refer to classes by their full path:

std::map<wxString, wxString> myMap; // GOOD

using namespace std;
map<wxString, wxString> myMap; // NOT GOOD

Casting / Memory management

Do not use C-style casting
To cast void* to a class, use reinterpret_cast.
Use dynamic_class where possible (e.g. when casting between wxClientData* and your own ClientData).
If you need const_cast it means that something is wrong with your code.
Release memory allocated with the new operator using the wxDELETE macro, which basically does:

if ( ptr ) {
    delete ptr;
    ptr = NULL;
}

Similarly, use wxDELETEA to release an array allocated on the heap.

Naming conventions

Class, function and method names start with an upper-case letter and use further upper-case letters to distinguish words (e.g. MyClassWithSeveralWords).
Class members starts with the m_ prefix followed by a lower-case letter and use further upper-case letters to distinguish words (e.g. m_isOk).

Bracketing

Start brackets for classes and functions should be placed on the next line

class Box
{
    void foo();
};

void Box::foo()
{
}

The start bracket for an inline function should be placed on the same line as the function name

class Box
{
    void foo() {
    }
};

Start brackets, '{', should be located on the line of the control structure they start; end brackets, '}', should be at the indented start of a line. When there is an 'else' clause, this goes on the same line as the '}'. This format uses fewer lines than alternatives, allowing more code to be seen on screen. Fully-bracketed control structures are preferred because this makes it more likely that modifications will be correct, and it allows Scintilla's code-folding to work

    if (a) {
        s();
        t();
    } else {
        u();
    }

Indentation

Use spaces to indent your code.
Use 4 spaces for a single TAB.

GUI Generation

Do not hand-craft the UI!
All UI code should be generated using wxCrafter.

CodingGuidelines