This page provides useful information for people wishing to contribute to CodeLite. It describes the coding style to be used by CodeLite developers, how to submit a patch and other useful information
Please read this page carefully.

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

    // Unknown OS

  • 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).


  • 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) {
    } else {


  • 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.
Edit - History - Print - Recent Changes - Search
Page last modified on September 01, 2014, at 09:52 PM