Logo Search packages:      
Sourcecode: virtualbox-ose version File versions  Download package

VBox Coding Guidelines

The VBox Coding guidelines are followed by all of VBox with the exception of qemu. Qemu is using whatever the frenchman does.

There are a few compulsory rules and a bunch of optional ones. The following sections will describe these in details. In addition there is a section of Subversion 'rules'.


(1) It is common practice on Unix to have a single symbol namespace for an entire process. If one is careless symbols might be resolved in a different way that one expects, leading to weird problems.

(2) This is common practice among most projects dealing with modules in shared libraries. The Windows / PE __declspect(import) and __declspect(export) constructs are the main reason for this. OTOH, we do perhaps have a bit too detailed graining of this in VMM...

64-bit and 32-bit

Here are some amendments which address 64-bit vs. 32-bit portability issues.

Some facts first:

Now for the guidelines:

C++ guidelines for Main

Main is currently (2009) full of hard-to-maintain code that uses complicated templates. The new mid-term goal for Main is to have less custom templates instead of more for the following reasons:

In particular, the following bits should be considered deprecated and should NOT be used in new code:

Generally, in many cases, a simple class with a proper destructor can achieve the same effect as a 1,000-line template include file, and the code is much more accessible that way.

Using standard STL templates like std::list, std::vector and std::map is OK. Exceptions are:

C++ guidelines for the Qt GUI

The Qt GUI is currently (2010) on its way to become more compatible to the rest of VirtualBox coding style wise. From now on, all the coding style rules described in this file are also mandatory for the Qt GUI. Additionally the following rules should be respected:


First part is the actual coding style and all the prefixes. The second part is a bunch of good advice.

The code layout

Variable / Member Prefixes

In new code in Main, use "m_" (and common sense). As an exception, in Main, if a class encapsulates its member variables in an anonymous structure which is declared in the class, but defined only in the implementation (like this: "class X { struct Data; Data *m; }"), then the pointer to that struct is called "m" itself and its members then need no prefix, because the members are accessed with "m->member" already which is clear enough.

Misc / Advice / Stuff

(1) Important, be very careful with the casting. In particular, note that a compiler might treat pointers as signed (IIRC).

(2) "A really advanced hacker comes to understand the true inner workings of the machine - he sees through the language he's working in and glimpses the secret functioning of the binary code - becomes a Ba'al Shem of sorts." (Neal Stephenson "Snow Crash")

Compiler Warnings

The code should when possible compile on all platforms and compilers without any warnings. That's a nice idea, however, if it means making the code harder to read, less portable, unreliable or similar, the warning should not be fixed.

Some of the warnings can seem kind of innocent at first glance. So, let's take the most common ones and explain them.

Signed / Unsigned Compare

GCC says: "warning: comparison between signed and unsigned integer expressions" MSC says: "warning C4018: '<|<=|==|>=|>' : signed/unsigned mismatch"

The following example will not output what you expect:

#include <stdio.h>
int main()
    signed long a = -1;
    unsigned long b = 2294967295;
    if (a < b)
        printf("%ld < %lu: true\n", a, b);
        printf("%ld < %lu: false\n", a, b);
    return 0;
If I understood it correctly, the compiler will convert a to an unsigned long before doing the compare.

Subversion Commit Rules

Before checking in:

After checking in:

(Inspired by mozilla tree rules.)

Generated by  Doxygen 1.6.0   Back to index