Robomongo Coding Style

In most cases we follow MongoDB style guides, which in turns tries to follow Google C++ Style Guide.

Basics

Use spaces, no literal tabs

In all cases, prefer spaces to tabs in source files. People have different preferred indentation levels, and different styles of indentation that they like; this is fine. What isn’t fine is that different editors/viewers expand tabs out to different tab stops. This can cause your code to look completely unreadable, and it is not worth dealing with.

4 spaces per indentation

Use 4 spaces for all indentations.

Use LF (Unix-style) line endings, not CR-LF (DOS)

Git will automatically manage line endings for you if you set the core.autocrlf option. This only need to be done when developing on Windows:

git config --global core.autocrlf true

Case

Use camelCase for most varNames. Use PascalCase for names of classes and structs. Use camelCase for instances of such classes.

class MongoDocument 
{
    void printAndGo(const std::string &textMessage) const 
    {
        int sizeLimit = 0;
        // ...
    }
}

Comments

We follow http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Comments for placement of comments.

As for style, we use javadocs in classes and methods (public or private):

/**
 * @brief Tab bar for WorkAreaTabWidget.
 */
class WorkAreaTabBar : public QTabBar
{
    Q_OBJECT

public:
    /**
     * @brief Creates WorkAreaTabBar, without parent widget. We are
     * assuming, that tab bar will be installed to (and owned by)
     * WorkAreaTabWidget, using QTabWidget::setTabBar().
     * @param parent Parent widget
     */
    WorkAreaTabBar(QWidget* parent=0);

    //...

private:
    /**
     * @brief Tab's context menu.
     */
    QMenu *_menu;

    // ..
};

We use simple comments inside methods and functions:

FindFrame *OutputItemContentWidget::configureLogText()
{
    FindFrame *logText = new FindFrame(this);
    logText->sciScintilla()->setLexer(_javaScriptLexer);

    // Wrap mode turned off because it introduces huge performance problems
    // even for medium size documents.
    logText->sciScintilla()->setWrapMode((QsciScintilla::WrapMode) QsciScintilla::SC_WRAP_NONE);

    return _logText;
}

Brackets

Classes, namespaces, methods and functions have the opening brace at the beginning of the next line:

class MongoDocument
{
    // ...
}

namespace Robomongo 
{
    // ...
}

void MongoDocument::print()
{
}

But for everything inside methods and functions put the opening brace last on the line:

if (0) {
    // ...
}
else if (0) {
    // ...
}
else {
    // ...
}

do {
    // ...
} while (0);

#includes

Use "double quotes" for Robomongo code, <angle brackets> for 3rd party or library headers, including MongoDB files:

#include <QStringList>
#include <boost/shared_ptr.hpp>
#include <mongo/client/dbclient.h>

#include "robomongo/core/Core.h"
#include "robomongo/core/MongoElement.h"

All of a project's header files should be listed as descendants of the project's src/ source directory without use of directory shortcuts (. and ..).

Correct:

#include "robomongo/core/MongoElement.h"

Wrong:

#include "core/MongoElement.h"
#include "../core/MongoElement.h"
#include "MongoElement.h"

Header (.h) files

Follow this order:

1. #pragma once at the top. Blank line.
2. Third party #includes, sorted. Blank line.
3. Robomongo #includes, sorted. Blank line.

Implementation (.cpp) files

1. Primary file #include, if applicable. Blank line.
2. Third party #includes, sorted. Blank line.
3. Robomongo #includes, sorted. Blank line.

Declaration Order

Your class declaration should be divided on 'access' sections in the following order:

1. public:
2. signals:
3. public slots:
4. protected slots:
5. protected:
6. private slots:
7. private:

If any of these sections are empty, omit them.

Within each section, the declaration should be in the following order:

1. Typedefs and Enums
2. Constants (static const data members)
3. Constructors
4. Destructor
5. Methods, including static methods
6. Data members

Method definitions in the corresponding .cpp file should be the same as the declaration order.

Do not put large method definitions inline in the class definition. Usually, only trivial or performance-critical, and very short, methods may be defined inline.