<html>
<head>
<link rel="stylesheet" href="llvm.css" type="text/css">
- <title>A Few Coding Standards</title>
+ <title>LLVM Coding Standards</title>
</head>
<body>
<div class="doc_title">
- A Few Coding Standards
+ LLVM Coding Standards
</div>
<ol>
<b>File Headers</b>
-<p>Every source file should have a header on it that
-describes the basic purpose of the file. If a file does not have a header, it
-should not be checked into CVS. Most source trees will probably have a standard
+<p>Every source file should have a header on it that describes the basic
+purpose of the file. If a file does not have a header, it should not be
+checked into Subversion. Most source trees will probably have a standard
file header format. The standard format for the LLVM source tree looks like
this:</p>
<div class="doc_code">
<pre>
//===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
-//
+//
// The LLVM Compiler Infrastructure
//
-// This file was developed by the LLVM research group and is distributed under
-// the University of Illinois Open Source License. See LICENSE.TXT for details.
-//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
//===----------------------------------------------------------------------===//
//
// This file contains the declaration of the Instruction class, which is the
file. This is important when printing out code and flipping though lots of
pages.</p>
-<p>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.</p>
+<p>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.</p>
<p>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
<li>System <tt>#includes</tt></li>
</ol>
-<p>... and each catagory should be sorted by name.</p>
+<p>... and each category should be sorted by name.</p>
<p><a name="mmheader">The "Main Module Header"</a> file applies to .cpp file
which implement an interface defined by a .h file. This <tt>#include</tt>
like to print out code and look at your code in an xterm without resizing
it.</p>
+<p>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).</p>
+
+<p>This is one of many contentious issues in coding standards, but is not up
+for debate.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<p>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.</p>
+specialization of templates. If these features are used, they should only be
+an implementation detail of a library which has a simple exposed API.</p>
</div>
<tt>#include</tt>'ing speeds up compilation.</p>
<p>It is easy to try to go too overboard on this recommendation, however. You
-<b>must</b> include all of the header files that you are using, either directly
+<b>must</b> include all of the header files that you are using -- you can
+include them either directly
or indirectly (through another header file). To make sure that you don't
accidently forget to include a header file in your module header, make sure to
include your module header <b>first</b> in the implementation file (as mentioned
<ol>
<li>The time to run the static c'tors impacts startup time of
- applications—a critical time for gui apps.</li>
+ applications—a critical time for GUI apps.</li>
<li>The static c'tors cause the app to pull many extra pages of memory off the
- disk: both the code for the static c'tors in each .o file and the small
- amount of data that gets touched. In addition, touched/dirty pages put
- more pressure on the VM system on low-memory machines.</li>
+ disk: both the code for the static c'tors in each <tt>.o</tt> file and the
+ small amount of data that gets touched. In addition, touched/dirty pages
+ put more pressure on the VM system on low-memory machines.</li>
</ol>
-<table align="center">
- <tbody>
- <tr>
- <th>Old Way</th>
- <th>New Way</th>
- </tr>
- <tr>
- <td align="left"><pre>#include <iostream></pre></td>
- <td align="left"><pre>#include "llvm/Support/Streams.h"</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>DEBUG(std::cerr << ...);
-DEBUG(dump(std::cerr));</pre></td>
- <td align="left"><pre>DOUT << ...;
-dump(DOUT);</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>std::cerr << "Hello world\n";</pre></td>
- <td align="left"><pre>llvm::cerr << "Hello world\n";</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>std::cout << "Hello world\n";</pre></td>
- <td align="left"><pre>llvm::cout << "Hello world\n";</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>std::cin >> Var;</pre></td>
- <td align="left"><pre>llvm::cin >> Var;</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>std::ostream</pre></td>
- <td align="left"><pre>llvm::OStream</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>std::istream</pre></td>
- <td align="left"><pre>llvm::IStream</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>std::stringstream</pre></td>
- <td align="left"><pre>llvm::StringStream</pre></td>
- </tr>
- <tr>
- <td align="left"><pre>void print(std::ostream &Out);
-// ...
-print(std::cerr);</pre></td>
- <td align="left"><pre>void print(std::ostream &Out);
-void print(std::ostream *Out) { if (Out) print(*Out) }
-// ...
-print(llvm::cerr);</pre>
-
-<ul><i>N.B.</i> The second <tt>print</tt> method is called by the <tt>print</tt>
-expression. It prevents the execution of the first <tt>print</tt> method if the
-stream is <tt>cnull</tt>.</ul></td>
- </tbody>
-</table>
+<p>Note that using the other stream headers (<tt><sstream></tt> for
+example) is allowed normally, it is just <tt><iostream></tt> that is
+causing problems.</p>
+
+<p>The preferred replacement for stream functionality is the
+<tt>llvm::raw_ostream</tt> class (for writing to output streams of various
+sorts) and the <tt>llvm::MemoryBuffer</tt> API (for reading in files).</p>
</div>
<p>You get the idea...</p>
+<p>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:</p>
+
+<div class="doc_code">
+<pre>
+assert(0 && "Some helpful error message");
+</pre>
+</div>
+
+<p>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.</p>
+
+<div class="doc_code">
+<pre>
+assert(0 && "Some helpful error message");
+// Not reached
+return 0;
+</pre>
+</div>
+
</div>
<!-- _______________________________________________________________________ -->
"<tt>using namespace std;</tt>".</p>
<p> In header files, adding a '<tt>using namespace XXX</tt>' directive pollutes
-the namespace of any source file that includes the header. This is clearly a
-bad thing.</p>
+the namespace of any source file that <tt>#include</tt>s the header. This is
+clearly a bad thing.</p>
<p>In implementation files (e.g. .cpp files), the rule is more of a stylistic
rule, but is still important. Basically, using explicit namespace prefixes
<p>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.
-</p>
+this, the compiler will copy the vtable and RTTI into every <tt>.o</tt> file
+that <tt>#include</tt>s the header, bloating <tt>.o</tt> file sizes and
+increasing link times.</p>
</div>
<ol>
-<li><a href="http://www.aw-bc.com/catalog/academic/product/0,1144,0201310155,00.html">Effective
-C++</a> by Scott Meyers. There is an online version of the book (only some
-chapters though) <a
-href="http://www.awlonline.com/cseng/meyerscddemo/">available as well</a>. Also
+<li><a href="http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective
+C++</a> by Scott Meyers. Also
interesting and useful are "More Effective C++" and "Effective STL" by the same
author.</li>
-<li><a href="http://cseng.aw.com/book/0,3828,0201633620,00.html">Large-Scale C++
-Software Design</a> by John Lakos</li>
+<li>Large-Scale C++ Software Design by John Lakos</li>
</ol>
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
<a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>