A Few Coding Standards

The next section in the file is a concise note that defines the license that -the file is released under. This makes it perfectly clear what terms the source -code can be distributed under.

The next section in the file is a concise note that defines the license +that the file is released under. This makes it perfectly clear what terms the +source code can be distributed under and should not be modified in any way.

The main body of the description does not have to be very long in most cases. Here it's only two lines. If an algorithm is being implemented or something @@ -240,7 +240,7 @@ order:

The "Main Module Header" file applies to .cpp file which implement an interface defined by a .h file. This #include @@ -264,6 +264,18 @@ implements are defined.

The longer answer is that there must be some limit to the width of the code +in order to reasonably allow developers to have multiple files side-by-side in +windows on a modest display. If you are going to pick a width limit, it is +somewhat arbitrary but you might as well pick something standard. Going with +90 columns (for example) instead of 80 columns wouldn't add any significant +value and would be detrimental to printing out code. Also many other projects +have standardized on 80 columns, so some people have already configured their +editors for it (vs something else, like 90 columns).

This is one of many contentious issues in coding standards, but is not up +for debate.

In practice, this means that you shouldn't assume much about the host compiler, including its support for "high tech" features like partial -specialization of templates. In fact, Visual C++ 6 could be an important target -for our work in the future, and we don't want to have to rewrite all of our code -to support it.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Old Way	New Way
#include <iostream>	#include "llvm/Support/Streams.h"
DEBUG(std::cerr << ...); -DEBUG(dump(std::cerr));	DOUT << ...; -DEBUG(dump(DOUT));
std::cerr << "Hello world\n";	llvm::cerr << "Hello world\n";
std::cout << "Hello world\n";	llvm::cout << "Hello world\n";
std::cin >> Var;	llvm::cin >> Var;
std::ostream	llvm::OStream
std::istream	llvm::IStream
std::stringstream	llvm::StringStream
void print(std::ostream &Out); -// ... -print(std::cerr);	void print(llvm::OStream Out);¹ -// ... -print(llvm::cerr); - -

Note that using the other stream headers (<sstream> for +example) is allowed normally, it is just <iostream> that is +causing problems.

¹llvm::OStream is a light-weight class so it should never -be passed by reference. This is important because in some configurations, -DOUT is an rvalue.

The preferred replacement for stream functionality is the +llvm::raw_ostream class (for writing to output streams of various +sorts) and the llvm::MemoryBuffer API (for reading in files).

Please be aware when adding assert statements that not all compilers are aware of +the semantics of the assert. In some places, asserts are used to indicate a piece of +code that should not be reached. These are typically of the form:

When used in a function that returns a value, they should be followed with a return +statement and a comment indicating that this line is never reached. This will prevent +a compiler which is unable to deduce that the assert statement never returns from +generating a warning.

In header files, adding a 'using namespace XXX' directive pollutes -the namespace of any source file that includes the header. This is clearly a -bad thing.

In implementation files (e.g. .cpp files), the rule is more of a stylistic rule, but is still important. Basically, using explicit namespace prefixes @@ -673,9 +657,70 @@ others.

If a class is defined in a header file and has a v-table (either it has virtual methods or it derives from classes with virtual methods), it must always have at least one out-of-line virtual method in the class. Without -this, the compiler will copy the vtable and RTTI into every .o file that -#includes the header, bloating .o file sizes and increasing link times. -

+ +

Because C++ doesn't have a standard "foreach" loop (though it can be emulated +with macros and may be coming in C++'0x) we end up writing a lot of loops that +manually iterate from begin to end on a variety of containers or through other +data structures. One common mistake is to write a loop in this style:

+ +

+  BasicBlock *BB = ...
+  for (BasicBlock::iterator I = BB->begin(); I != BB->end(); ++I)
+     ... use I ...
+

+ +

The problem with this construct is that it evaluates "BB->end()" +every time through the loop. Instead of writing the loop like this, we strongly +prefer loops to be written so that they evaluate it once before the loop starts. +A convenient way to do this is like so:

+ +

+  BasicBlock *BB = ...
+  for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I)
+     ... use I ...
+

+ +

The observant may quickly point out that these two loops may have different +semantics: if the container (a basic block in this case) is being mutated, then +"BB->end()" may change its value every time through the loop and the +second loop may not in fact be correct. If you actually do depend on this +behavior, please write the loop in the first form and add a comment indicating +that you did it intentionally.

+ +

Why do we prefer the second form (when correct)? Writing the loop in the +first form has two problems: First it may be less efficient than evaluating it +at the start of the loop. In this case, the cost is probably minor: a few extra +loads every time through the loop. However, if the base expression is more +complex, then the cost can rise quickly. I've seen loops where the end +expression was actually something like: "SomeMap[x]->end()" and map +lookups really aren't cheap. By writing it in the second form consistently, you +eliminate the issue entirely and don't even have to think about it.

+ +

The second (even bigger) issue is that writing the loop in the first form +hints to the reader that the loop is mutating the container (a fact that a +comment would handily confirm!). If you write the loop in the second form, it +is immediately obvious without even looking at the body of the loop that the +container isn't being modified, which makes it easier to read the code and +understand what it does.

+ +

While the second form of the loop is a few extra keystrokes, we do strongly +prefer it.