VisIt Coding Style Guide

This wiki describes the coding conventions used by VisIt developers and contributors. We encourage the use of this coding style to ensure that the code is easily written in a consistent format, readable by all developers. We also include some coding conventions that increase the likelihood of creating portable code since VisIt is built on many platforms.

Naming conventions

  • Class names start with capital letters, (eg Mesh). If a class name has multiple words, capitalize the first letter of each word, (eg RectilinearMesh). Exceptions can be made to help group classes in a package (eg vtkRectilinearMesh).
  • Fields and variables have the first letter uncapitalized and the first letter for each subsequent word capitalized, (eg theImportantValue).
  • Methods and functions follow the same naming convention as classes. The distinction between methods and classes will be clear because methods will always have attached parentheses. This is not true when a function is passed as a pointer, but that should be clear from context.
  • Try to avoid using the following names as they are reserved by ANSI for future expansion:
E[0-9A-Z][0-9A-Za-z]* errno values
is[a-z][0-9A-Za-z]* Character classification
to[a-z][0-9A-Za-z]* Character manipulation
LC_[0-9A-Za-z_]* Locale
SIG[_A-Z][0-9A-Za-z_]* Signals
str[a-z][0-9A-Za-z_]* String manipulation
mem[a-z][0-9A-Za-z_]* Memory manipulation
wcs[a-z][0-9A-Za-z_]* Wide character string manipulation

File Structure

File Names

A file containing the definition for class Foo will be named Foo.h. A file containing the methods for the class Foo will be named Foo.C.

.h File Contents

Each of the .h files will have the following format:

Class Description
Class Definition
Variable Declarations
Inline Functions
  • The ifndef is used to prevent the class from being defined multiple times.
    • To prevent name collisions, the symbolic name being defined should be the class name in all capital letters, with each word separated by underscores. _H should be appended.
  • Forward declare classes rather than including their header file when possible but be sure to use the correct struct or class keyword in the forward declaration.
  • Only one class should be defined per file. Exceptions can be made for very closely related classes.
  • Inline functions should only be included in the .h file if they are public or protected. Private * inline functions should be placed in the .C file for that class.
    • Note that public and protected inline functions should be used sparingly. All code that includes the header must be recompiled if the function is changed.
  • The .h file should be valid as a stand alone file.
    • If other header files are included before this files inclusion, it may be making use of their definitions.
  • All variables declared here should be externed. Class-scoped static variables should not be defined here.
  • Avoid using directives in header files. They will effect not only the current header file but any files in which the header file is included, directly or indirectly.
  • See these additional comments other_header_file_issues

.C File Content

Each of the .C files will have the following format:

Variable Declarations
Static Function Prototypes
Method Definitions
Friend Functions
Static Functions

The friend operators included in the .C file must be directly related to the class whose methods are defined in that file.

Copyright notice

The copyright notice shall appear at the top of each .C, .h, .java, CMakeLists.txt, and Python sources.

* Copyright (c) 2000 - 2011, Lawrence Livermore National Security, LLC
* Produced at the Lawrence Livermore National Laboratory
* LLNL-CODE-442911
* All rights reserved.
* This file is  part of VisIt. For  details, see  The
* full copyright notice is contained in the file COPYRIGHT located at the root
* of the VisIt distribution or at
* Redistribution  and  use  in  source  and  binary  forms,  with  or  without
* modification, are permitted provided that the following conditions are met:
*  - Redistributions of  source code must  retain the above  copyright notice,
*    this list of conditions and the disclaimer below.
*  - Redistributions in binary form must reproduce the above copyright notice,
*    this  list of  conditions  and  the  disclaimer (as noted below)  in  the
*    documentation and/or other materials provided with the distribution.
*  - Neither the name of  the LLNS/LLNL nor the names of  its contributors may
*    be used to endorse or promote products derived from this software without
*    specific prior written permission.


  • Include files should use angle brackes. For example: #include <vtkRectilinearGrid.h>
  • Class.C should include Class.h first. This is to make sure that Class.h is not using any previously declared headers. Class.C file may use quotes instead of angle brackets to include Class.h.
  • Include files should be grouped from wider scope to narrower scope. This leads to grouping the include files in the following order:
    • System include files. Examples are: <math.h>, <stdio.h>.
    • X and Qt include files. Examples are: <Xlib.h>, <qgl.h>.
    • Library include files. Examples are: <dmf.h>, <vtk.h>.
    • Class definition files. Examples are: <Mesh.h>, <Field.h>.
    • Within a group, include files should be listed alphabetically.
  • If the include files must be listed in a specific order, which is not alphabetic, then a comment must be added justifying it.
  • Some C header files contain C++ keywords that cause compilations to fail. With the exception of header files for the standard C library, X, and Motif, all C header files must be wrapped with an extern C directive.
extern "C" {
#include <hdf5.h>

Forbidden Constructs

exit() and abort()

Please do not use exit() or abort() in your code since we do not want VisIt to fail unexpectedly. Use exceptions instead. VisIt's check-in svn hooks will not permit unconditionally compiled code calling exit or abort to be checked-in.

using statements

using statements of any kind are not permitted in header files since they can indirectly cause compilation problems for other compilation units that may include your header file either directly or indirectly. In header files, you will have to use the fully qualified class name for any class you need to refer to. (e.g. std::vector and not just vector). Yes, this does make for somewhat uglier header files but it also prevents a lot of problems. VisIt's check-in svn hooks will not permit code containing using statements in a header file.

In source files, when you need to use using statements, we prefer that you narrow the scope of the statement as much as is practical. So, please don't use using namespace std to use something like std::string. Instead use using std::string.

Class Description

Each class must have a brief description, like the below example.

// ********************************************************
// Class: Example
// Purpose:
//   What this class does.
// Notes:     Any special notes for users of the class.
// Programmer: Joe Smith
// Creation: August 29, 2007
// Modifications:
//   Joe Smith, Fri Oct 15 13:31:51 EST 2007
//   I added a new method to do ...
// ********************************************************

It is important to use these category names because they will be picked up by doxygen to create our documentation. The asterisks should fill out the line, 76 asterisks in all. The category labels (Class, Purpose, etc) should be indented two spaces past the comment (//). When the text after a category label wraps to the following line, it should be indented fours spaces after the comment.

Class Definition

Class definitions should follow these rules:

  • There should be no public fields. They violate the basic object-oriented philosophy of data hiding.
  • The sections inside the class should be ordered public, protected, private. This way users of the class can stop reading when they reach protected/private. The fields in each section should be grouped together, as should the methods.
  • All inheritance should be public to avoid confusion, bar good reason.
  • Every non-trivial field should have a comment preceding it that describes its purpose. This comment will be picked up by doxygen when the documentation is built.
  • Friends should be avoided when possible. When it is necessary to grant friend access to a series of derived types, grant it only to their base type and define protected methods for the base type that access the class.
  • Define a copy constructor and assignment operator for every class.
  • Constructor and destructor method definitions should never appear in the class header file because of compiler bugs on some platforms.
  • Note that C++ automatically provides a constructor, a copy constructor, an assignment operator, two address-of operators, and a destructor for you:
// You write
class Empty { };
// You get
class Empty
    Empty() {};
    ~Empty() {};
    Empty(const Empty &);
    Empty &operator=(const Empty &);
    Empty *operator&();
    const Empty *operator&() const;
  • If you are redefining a pure virtual method that should not be used, declare it private and have it throw an exception.
  • The copy constructor and assignment operator provided by the compiler perform blind copies, meaning that pointers will also be copied, potentially introducing many bugs.

This is because many publicly available libraries, such as STL, use these methods.

Method Structure

The structure of a method should follow this format:



Each method must have a prologue with the following format:

// ********************************************************
// Method: ClassName::MethodName
// Purpose: 
//   What this method does.
// Arguments:
//   arg1 : What the first argument does...
//   arg2 : What the second argument does...
//   ...
// Returns:  <0 on failure, 0 on success.
// Note: Assumes coordinates have already been read.
// Programmer: Joe VisIt
// Creation: August 29, 2007
// Modifications:
//   Joe VisIt, Fri Oct 15 13:31:51 EST 2007
//   Fixed bug with ...
// ********************************************************

The category label Method can be replaced Function, Operator, Constructor, or Destructor and still be accepted by doxygenate.


The definition should follow this form:

Zone * 
RectilinearMesh::GetZone(int i, int j, int k)

If multiple lines are needed for all of the arguments, each subsequent line should be indented to the opening parenthesis, or if that is too far, 4 spaces.



The body should be small. Try to keep functions under 100 lines. This promotes clarity and correctness. This tradeoff should not be paid for a substantial speed penalty, however.


  • All input arguments passed by reference should be declared const.
  • Unused arguments should not be named. Note that this eliminates the need for the lint directive ARGSUSED.


  • Variables should be declared near their first use.
  • Variable names may not coincide with any of the class' field names.
  • All local pointer variables should be set to NULL or 0 when declared. This helps with later tracking of memory problems when looking at core files.
  • Associate `*' and `&' with the variable, not with the type.

For example, the following code:

int* i, j;

misleads the reader into thinking both i and j are pointers to ints, while j is actually only an int.

  • Only use variables declared in the initializer list of a for loop inside that for loop.

The code fragments:

   for (int i = 0 ; i < size; i++)
      { ... }
   for (int i = 0 ; i < length ; i++)
      { ... }


   for (int i = 0 ; i < size ; i++)
      { ... }
   if (i == size)


  • Avoid using C-style comments. This way, when debugging, they can be used to comment out long blocks of code without worrying about nested comments.
  • Indent comments to the same level as the statement to which they apply.
  • Both block and single line comments are acceptable, but when modifying a pre-existing file, they should follow its convention.
  • Comments are highly encouraged!

Control Structures

  • Use `for (;;)' instead of `while(1).' They both result in infinite loops, but `while(1)' is flagged by many compilers as a constant condition. This eliminates the need for the lint directive CONSTCOND in this case.
  • Any case of a switch statement that does not end with a break should have a FALLTHRU comment to show that this is intentional.
  • When the body of a for or while is empty, place a continue in it to make the intent clear.

The following code:

for (int i = 0; p[i] != `\0' ; i++);

Is more clearly represented as:

for (int i = 0; p[i] != `\0' ; i++)

Also note that this eliminates the need for the lint directive EMPTY in this case.


  • TAB characters are NOT ALLOWED in VisIt source code.
  • Semicolons should immediately follow the last character. (i.e. there is no space between the last character in a statement and its semicolon).
  • Lines should not exceed 79 characters in length. Note that it is not necessary to violate this rule for strings.
char *str1 = "Hello world";
char *str2 = "Hello "

In the code above, str1 is equal to str2.

  • All variable declarations should occur on separate lines unless closely related (e.g. int i, j, k;).
  • Do not use any tabs in the source. Use `\t' to simulate a tab in a string.
  • The parenthesis of a function should immediately follow the function name. This makes searching easier for functions with common names.
  • There should not be any spaces surrounding the `.' or `->', operators and no spaces preceding a `[' operator.
  • An indentation block is four spaces.
  • The labels case, public, protected, and private are indented 0 or two spaces.
  • Any time a new block is started, a `{` should be put on the following line at the same indentation level. The next statement should be indented an additional four spaces.
  • Within reason, adding whitespace to line up parentheses or brackets on consecutive lines is encouraged, even when it violates one of the previous rules.


Automatic source code reformatting may be performed using a program called artistic style. Here is some basic usage that reformats a source file into a form compatible with VisIt coding style:

astyle --brackets=break < inputfile > outputfile

End of line

The UNIX convention for end of line characters must be followed for VisIt source code.


  • Macros should only be used if the # or ## operators are used.
  • Any macros used to define a constant should be declared as a const global variable.
  • Parameterized macros used to perform a short routine should be implemented as an inline.
  • Macros should only be used if the # or ## operators are used.
  • The code inside the #ifdef section should be indented as if the #ifdef were not present.
  • Comments should not be added on the same line after preprocessor directives because some compilers do not accept them.
  • Preprocessor directives should have the `#' in column 1.

Pointer vs. References

References are preferred over pointers. References:

  • Always refer to a real object.
  • Do not change objects they refer to.


  • Can represent no object (NULL).
  • Can change the object they refer to.
  • Can represent an array.
  • Can represent a location (like the end of an array).

Caveats for ensuring that VisIt builds on Windows

The rules that have been covered before in this document apply mainly to source code style and are conventions to simplify maintenance. This section describes some source code constructs that must be avoided at all times in order to ensure compatibility with the Microsoft Windows Visual C++ (MSVC). Windows is an important development platform for VisIt. Adhering to these additional coding rules will reduce the amount of time required to fix minor source code problems that burden Windows developers.

API macros

VisIt's header files have API macros that help the MSVC (all versions) compiler and linker produce dynamic link libraries (DLLs) and their associated import libraries. A DLL is a file containing executable code which is loaded by an application at runtime and all applications that require the code stored in the DLL use the same instance of the DLL in the computer's memory, which saves resources. An import library is a small stub library that contains enough symbolic information to satisfy the linker so that all unresolved symbols are resolved at link time and still allowing the application code to be loaded dynamically at runtime. This link step is mostly avoided on other platforms where VisIt's libraries are linked exclusively at runtime. Import libraries are difficult to create manually due to the amount of symbols in all of VisIt's libraries so the VisIt source code has been augmented with API macros that allow the compiler to automatically create the import libraries. VisIt's API macros come from an API include file and there is one API include file per VisIt library. The name of the API include file is usually the name of the library appended with the "_exports.h" suffix. The API macro is added to class declarations when the class should be made accessible to other VisIt libraries.

#include <example_exports.h>

class EXAMPLE_API MyExampleClass
    virtual ~MyExampleClass();

void EXAMPLE_API example_exported_function();
void this_function_not_exported();

In the above example, the header file that gets included defines the EXAMPLE_API macro, which tells the MSVC compiler to add the flagged symbols to its list of symbols for the import library that goes along with the DLL that contains the class. The EXAMPLE_API macro evaluates to whitespace on other platforms so its inclusion in VisIt's source code is not disruptive. Note that the EXAMPLE_API macro has been applied to a class and to a function to ensure that both the class's methods and the function are both added to the import library. Any class, function, variable, etc that lacks an export macro is not added to the import library and will not be available to other programs or libraries. Now that the mechanism by which symbols are added to import libaries has been explained, suppose that you move a class from one library to another. What happens? Well, the answer is that the class will be compiled into the new library but it will not be put into the import library because its API macro was not changed. To avoid this problem, it is very important that when you move classes from one library to another library that you change the class so it uses the appropriate API macro for the new host library. This goes especially for VTK classes that have become part of one of VisIt's libraries.

Include visitstream.h instead of iostream.h

VisIt relies on many stream classes and older versions of MSVC provide two different stream class hierarchies. One stream class hierarchy is compatible with STL, the other one is not. Furthermore, MSVC6 has issues with strings and both versions of the stream class hierarchy. To avoid these problems on Windows and on other platforms, VisIt coding style prohibits the inclusion of any of the stream header files. When you need to use streams, include <visitstream.h>. The <visitstream.h> header file includes the stream header files that are compatible with the VisIt source code and the MSVC compiler.

You still need std:: for iterators

It is fair practice to use the using statement within a .C file so that namespace qualification is not required. For example, if you wanted to use the std::map class but did not want to call it std::map everywhere, you could add: using std::map to your source code and then use the map class.

#include <map>
using std::map;
map<int, int> M;

It is typical to instantiate a variable of an STL container class such as std::map and then iterate through it using iterators. Normally, you would just declare an iterator without the std:: if you've used the using statement for the class over which you want to iterate. Old versions of MSVC prevent this due to an apparent flaw in its namespace resolution.

#include <map>
using std::map;
map<int, int> M;

// This does not work using MSVC6
for(map<int,int>::const_iterator it = M.begin(); it != M.end(); ++it)
{ /*code*/ }

// But this does work
for(std::map<int,int>::const_iterator it = M.begin(); it != M.end(); ++it)
{ /* code */ }

Note that you can avoid this bug in MSVC6 if you use typedefs.

#include <map>
using std::map;
// Define a type based on map.
typedef map<int,int> IntIntMap;
IntIntMap M;
for(IntIntMap::const_iterator it = M.begin(); it != M.end(); ++it)
{ /* code */}

No constructor or destructor definitions in header file

Do not put class constructor or destructor definitions in the class header file. When you put class constructors and destructors in the class header file, MSVC gets confused when you attempt to use the class from another DLL because sometimes the virtual method table is messed up when the constructor and destructor are placed in the header file possibly due to function inlining. When this happens, it is impossible to successfully link against the library that is supposed to contain your class. To be safe, always create a .C file that contains the constructor and destructors for your class.

#ifndef MY_CLASS_H
#define MY_CLASS_H
#include <mylib_exports.h>
class MYLIB_API MyClass
    // Never do this
    MyClass() { };
    virtual ~MyClass() { };

Do this instead:

MyClass.h file contents:

#ifndef MY_CLASS_H
#define MY_CLASS_H
#include <mylib_exports.h>
class MYLIB_API MyClass
    virtual ~MyClass();

MyClass.C file contents:

#include <MyClass.h>
MyClass::MyClass() { }
MyClass::~MyClass() { }

Include snprintf.h

VisIt source code should not use sprintf into a static sized buffer due to the possibility of buffer overruns, which introduce memory problems and possible security threats. To combat this, the use of sprintf is deprecated and all new code should use snprintf, which behaves the same but also takes the size of the buffer as an argument so buffer overruns are not possible. The snprintf function is not supported in any of the Windows header files but there is a _snprintf function. Since some platforms can use snprintf and Windows must use _snprintf, there is an snprintf.h header file that defines an SNPRINTF macro which evaluates to the proper symbol based on the compiler being used.

// Don't do this
const char *s = "This is a very long message "
"intended to overrun the buffer.";
char buf[20];
sprintf(buf, "Message: %s", s);

// Do this instead
#include <snprintf.h>
SNPRINTF(buf, 20, "Message: %s", s);

Do not use long long type

Some code in VisIt needs to use very large integers that exceed the precision of 32 bits. In these cases, the logical thing to do is use the long long type if you are on a 32 bit computer. Unfortunately, the long long type is not supported by MSVC 6. Instead of long long, you can use VISIT_LONG_LONG so that you have access to a 64 bit integer type. The VISIT_LONG_LONG macro actually evaluates to __int64 on Windows so you retain the ability to use 64 bits of integer precision without the use of long long.

// Don't do this
long long nZones = 100000000000000;

// Do this instead
VISIT_LONG_LONG nZones = 100000000000000;

Do not use variables called near or far

The MSVC compiler reserves the near and far keywords for backward compatibility with older 16-bit versions of the compiler that used near and far to determine pointer size. Do not use near or far for variable names because it will cause a strange compiler error.

Do not create a file called parser.h

Windows provides a file called parser.h and if you also provide such a file, you had better change the include directory order or you will run into hundreds of errors when the compiler uses Microsoft's parser.h instead of yours.

Do not create functions or methods called GetMessage

The WIN32 API is used in certain places in VisIt to implement Windows-specific functionality. Occasionally, we have run into problems where VisIt classes have names such as GetMessage. The windows.h include file defines a macro called GetMessage and sets it to GetMessageEx. This caused the preprocessor to replace all GetMessage method calls on a VisIt object with GetMessageEx, which is not a method of the object. Needless to say, this is a confusing compilation problem. Steer clear of defining method names that conflict with WIN32 macro names!

Comparing QString and std::string

Call the .toStdString() method to compare QString to std::string.


QString string1("my q string");
std::string string2("my std string");

// Do this:
if (string1.toStdString() == string2))

Do not use unistd.h

Windows does not have the unistd.h header file so do not use functions from it without making conditionally compiled code.

#if defined(_WIN32)
    // Windows implementation ...
    #include <unistd.h>
    // Unix implementation ...

Do not use libgen.h

Windows does not have libgen.h, which is sometimes used for functions such as dirname(), basename(). Refrain from using functions from libgen or provide a Windows implementation as well.

Sign of size() method return value

The .size() method for STL containers returns a size_t. Be aware if you attempt to do arithmetic on the value returned by .size()


// Consider what happens when the following code is
// executed with myvector being empty (size is zero)
if (val > myvector.size()-1) // if test fails
myvector[val] =  ... // SEGV!

Caveats for building on other platforms

Conversion between QString and std::string on AIX

On AIX systems assigning a QString to a std::string results in a runtime linking error that will prevent the GUI from launching.


QString qstring("my important q string");
// This will cause a hard to find linking error on AIX:
std::string my_string = qstring;
// Do this instead:
std::string my_string = qstring.toStdString();