qt-creator/doc/coding-style.qdoc

/****************************************************************************
**
** This file is part of Qt Creator
**
** Copyright (c) 2010 Nokia Corporation and/or its subsidiary(-ies).
**
** Contact: Nokia Corporation (qt-info@nokia.com)
**
** No Commercial Usage
**
** This file contains pre-release code and may not be distributed.
** You may use this file in accordance with the terms and conditions
** contained in the Technology Preview License Agreement accompanying
** this package.
**
** GNU Free Documentation License
**
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of this
** file.
**
** If you have questions regarding the use of this file, please contact
** Nokia at qt-info@nokia.com.
**
****************************************************************************/

/*!

\contentpage{index.html}{Qt Creator}
\page coding-style.html

\title Qt Creator Coding Rules

THIS IS PRELIMINARY.

\section1 Introduction

The aim of this section is to serve as a guide for the developers, to aid us
to build understandable and maintainable code, to create less confusion and
surprises when working on Qt Creator.

As usual: Rules are not set in stone. If there's a good reason to break one,
do it, preferably after making sure that there are others agreeing.

This document is incomplete.

In general, if you want to contribute to the main source, we expect at least
that you:

\list 1
\o The most important rule first: KISS (keep it simple ...): always
   use a simple implementation in favor of a more complicated one.
   This eases maintenance a lot.
\o Write good C++ code: Readable, well commented when necessary,
   and taking advantage of the OO model. Follow the \l{Formatting} guidelines.
   There are also certain \l{Code Constructs} that we try to follow.
\o Adapt the code to the structures already existing in Qt Creator, or in
   the case that you have better ideas, discuss them with other developers
   before writing the code.
\o Take advantage of Qt. Don't re-invent the wheel. Think about what parts
   of your code are generic enough that they might be incorporated into
   Qt proper.
\o Document interfaces. Right now we use qdoc, but changing to doxygen
   is being considered.
\endlist


\section1 Submitting Code

See http://qt.gitorious.org/qt/pages/QtContributionGuidelines

\section1 Code Constructs

We have several guidelines on code constructs, some of these exist to
make the code faster, others to make the code clearer. Yet others
exist to allow us to take advantage of the strong type checking
in C++.

\list 1
\o Declaration of variables should wait as long as possible. The rule
  is: "Don't declare it until you need it." In C++ there are a lot of
  user defined types, and these can very often be expensive to
  initialize. This rule connects to the next rule too.

\o Make the scope of a variable as small as possible.

\o Prefer preincrement to postincrement whenever possible.
  Preincrement has potential of being faster than postincrement. Just
  think about the obvious implementations of pre/post-increment. This
  rule applies to decrement too.

\code
	++T;
	--U;
	-NOT-
	T++; // not used in Qt Creator
	U--; // not used in Qt Creator
\endcode

\o Try to minimize evaluation of the same code over and over. This is
   aimed especially at loops.

\code

	Container::iterator end = large.end();
	for (Container::iterator it = large.begin(); it != end; ++it) {
		...;
	}
	-NOT-
	for (Container::iterator it = large.begin();
	     it != large.end(); ++it) {
		...;
	}
\endcode


\o Using Qt's foreach is ok in non-time critical code when using a QTL
   container. It is a nice way to keep line noise down and to give the
   loop variable a proper name:

\code
        foreach (QWidget *widget, container)
            doSomething(widget);

        -VS-

	Container::iterator end = container.end();
	for (Container::iterator it = container.begin(); it != end; ++it)
            doSomething(*it);
\endcode

    If the loop variable can be made const, do so. This can prevent
    unnecessary detaching of shared data in some cases. So:

\code
        foreach (const QString &name, someListOfNames)
            doSomething(name);

        - NOT -

        foreach (QString name, someListOfNames)
            doSomething(name);
\endcode


\section1 Formatting

\section2 Declarations

Only one declaration on each line.
\code
	int a;
	int b;
	-NOT-
	int a, b; // not used in Qt Creator
\endcode

  This is especially important when initialization is done at the same
  time.
\code
	QString a = "Joe";
	QString b = "Foo";
	-NOT-
	QString a = "Joe", b = "Foo"; // not used in Qt Creator
\endcode
	[Note that 'QString a = "Joe"' is formally calling a copy constructor
	on a temporary constructed from a string literal and therefore has the
	potential of being more expensive then direct construction by
	'QString a("joe")'. However the compiler is allowed to elide the copy
	(even if it had side effects), and modern compilers typically do so.
	Given these equal costs, Qt Creator code favours the '=' idiom as it is in
	line with the traditional C-style initialization, _and_ cannot be
	mistaken as function declaration, _and_ reduces the level of nested
	parantheses in more initializations.]


\section2  Pointers and references

\code
	char *p = "flop";
	char &c = *p;
	-NOT-
	char* p = "flop"; // not used in Qt Creator
	char & c = *p;     // not used in Qt Creator
\endcode

  This is simply in line with the official Qt guide lines.

  Also note that we will have:
\code
	const char *p;
	-NOT-
	char const * p; // not used in Qt Creator
\endcode


  Using a plain 0 for Null pointer constants is always correct and least effort
  to type. So:
\code
	void *p = 0;
	-NOT-
	void *p = NULL; // not used in Qt Creator
	-NOT-
	void *p = '\0'; // not used in Qt Creator
	-NOT-
	void *p = 42 - 7 * 6; // also not used in Qt Creator
\endcode
  Note: As an exception, imported third party code as well as code
  interfacing the "native" APIs (src/support/os_*) can use NULL.


\section2  Operator names and parentheses
\code
	operator==(type)
	-NOT-
	operator == (type)  // not used in Qt Creator
\endcode

  The == is part of the function name, separating it makes the
  declaration look like an expression.


\section2 Function names and parentheses
\code
	void mangle()
	-NOT-
	void mangle ()  // not used in Qt Creator
\endcode



\section2 Naming rules

  Simply follow the style of Qt proper. As examples:
 \list
  \o Use descriptive but simple and short names. Do not abbreviate.

  \o Class names are capitalized, and function names lowercased.
    Enums are named like Classes, values are in lower-case.
\endlist



\section2 Formatting
   We are using the Qt Coding style, please follow the guidelines below.

Indentation
  4 spaces, no tabs

Declaring variables
  Declare each variable on a separate line
  Avoid short (e.g., a,rbarr,nughdeget) names whenever possible
  Single character variable names are only okay for counters and temporaries, where the purpose of the variable is obvious
  Wait with declaring a variable until it is needed

  Variables and functions start with a small letter. Each consecutive word in a variable's name starts with a capital letter
  Avoid abbreviations

    // Wrong
    int a, b;
    char *c, *d;

    // Correct
    int height;
    int width;
    char *nameOfThis;
    char *nameOfThat;

Whitespace
  Use blank lines to group statements together where suited
  Always use only one blank line
  Always use a single space after a keyword, and before a curly brace.

\code
    // Wrong
    if(foo){
    }

    // Correct
    if (foo) {
    }
\endcode

  For pointers or references, always use a single space before '*' or '&', but never after.
  Avoid C-style casts when possible.
\code
    // Wrong
    char* blockOfMemory = (char* ) malloc(data.size());

    // Correct
    char *blockOfMemory = (char *)malloc(data.size());
    char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));
\endcode
  Of course, in this particulare case, using \c new might be an even better
  option.

Braces
  As a base rule, the left curly brace goes on the same line as the start of the statement:
\code
    // Wrong
    if (codec)
    {
    }

    // Correct
    if (codec) {
    }
\endcode

  Exception: Function implementations and class declarations always have the left brace on the start of a line:
\code
    static void foo(int g)
    {
        qDebug("foo: %i", g);
    }

    class Moo
    {
    };
\endcode

  Use curly braces when the body of a conditional statement contains more than one line, and also if a single line statement is somewhat complex.
\code
    // Wrong
    if (address.isEmpty()) {
        return false;
    }

    for (int i = 0; i < 10; ++i) {
        qDebug("%i", i);
    }

    // Correct
    if (address.isEmpty())
        return false;

    for (int i = 0; i < 10; ++i)
        qDebug("%i", i);
\endcode

  Exception 1: Use braces also if the parent statement covers several lines / wraps
\code
    // Correct
    if (address.isEmpty() || !isValid()
        || !codec) {
        return false;
    }
\endcode

  Exception 2: Use braces also in if-then-else blocks where either the if-code or the else-code covers several lines
\code
    // Wrong
    if (address.isEmpty())
        --it;
    else {
        qDebug("%s", qPrintable(address));
        ++it;
    }

    // Correct
    if (address.isEmpty()) {
        --it;
    } else {
        qDebug("%s", qPrintable(address));
        ++it;
    }

    // Wrong
    if (a)
        if (b)
            ...
        else
            ...

    // Correct
    if (a) {
        if (b)
            ...
        else
            ...
    }
\endcode

  Use curly braces when the body of a conditional statement is empty
\code
    // Wrong
    while (a);

    // Correct
    while (a) {}
\endcode

Parentheses
  Use parentheses to group expressions:
\code
    // Wrong
    if (a && b || c)

    // Correct
    if ((a && b) || c)

    // Wrong
    a + b & c

    // Correct
    (a + b) & c
\endcode

Line breaks
  Keep lines shorter than 100 characters; insert line breaks if necessary.
  Commas go at the end of a broken line; operators start at the beginning of the new line. The operator is at the end of the line to avoid having to scroll if your editor is too narrow.
\code
    // Wrong
    if (longExpression +
        otherLongExpression +
        otherOtherLongExpression) {
    }

    // Correct
    if (longExpression
        + otherLongExpression
        + otherOtherLongExpression) {
    }
\endcode


\section2 Declarations

  - Use this order for the access sections of your class: public,
    protected, private. The public section is interesting for every
    user of the class. The private section is only of interest for the
    implementors of the class (you). [Obviously not true since this is
    for developers, and we do not want one developer only to be able to
    read and understand the implementation of class internals. Lgb]

  - Avoid declaring global objects in the declaration file of the class.
    If the same variable is used for all objects, use a static member.

  - Avoid global or static variables.


\section2 API/ABI stability
  We currently do not gurantee any API nor ABI compatibility between releases.


\section2 File headers

  If you create a new file, the top of the file should include a
  header comment equal to the one found in other source files of Qt Creator.

\section2 Include order

  Always go from less general to more general. In a typical implementation
  file that would look like
\code
  #include "myownheader.h"
  ...
  #include "other_headers_from_my_own_plugin.h"
  ...
  #include <other_plugin/headers_from_other_plugin.h>
  ...
  #include <QtCore/QSomeCoreClass>
  ...
  #include <QtGui/QSomeGuiClass>
  ...
  #include <some_system_C++_header>
  ...
  #include <some_system_C_header>
\endcode
  This order ensures that the headers are self-contained.

  Using <...> instead of "..." for headers from other plugins helps
  spotting plugin-external dependencies in the sources.

  Using empty lines between blocks of "peer" headers are encouraged.

\section2 Documentation

  The documentation is generated from source and header files.
  You document for the other developers, not for yourself.
  In the header you should document interfaces, i.e.  what the function does,
   not the implementation.
  In the .cpp files you document the implementation if the implementation
  in non-obvious.


*/