Private</a></li>
<li><a href="#hl_earlyexit">Use Early Exits and 'continue' to Simplify
Code</a></li>
+ <li><a href="#hl_else_after_return">Don't use "else" after a
+ return</a></li>
<li><a href="#hl_predicateloops">Turn Predicate Loops into Predicate
Functions</a></li>
</ol></li>
<b>Method information</b>
<p>Methods defined in a class (as well as any global functions) should also be
-documented properly. A quick note about what it does any a description of the
+documented properly. A quick note about what it does and a description of the
borderline behaviour is all that is necessary here (unless something
-particularly tricky or insideous is going on). The hope is that people can
+particularly tricky or insidious is going on). The hope is that people can
figure out how to use your interfaces without reading the code itself... that is
the goal metric.</p>
<div class="doc_text">
<p>In all cases, prefer spaces to tabs in source files. People have different
-prefered indentation levels, and different styles of indentation that they
+preferred indentation levels, and different styles of indentation that they
like... this is fine. What isn't is that different editors/viewers expand tabs
out to different tab stops. This can cause your code to look completely
unreadable, and it is not worth dealing with.</p>
declare the symbol. This can lead to problems at link time.</p>
<p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless
-<b>all</b> members are public, in which case <tt>struct</tt> is allowed.</p>
+<b>all</b> members are public and the type is a C++ "POD" type, in which case
+<tt>struct</tt> is allowed.</p>
</div>
<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
+accidentally 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
above). This way there won't be any hidden dependencies that you'll find out
about later...</p>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="hl_else_after_return">Don't use "else" after a return</a>
+</div>
+
+<div class="doc_text">
+
+<p>For similar reasons above (reduction of indentation and easier reading),
+ please do not use "else" or "else if" after something that interrupts
+ control flow like return, break, continue, goto, etc. For example, this is
+ "bad":</p>
+
+<div class="doc_code">
+<pre>
+ case 'J': {
+ if (Signed) {
+ Type = Context.getsigjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_sigjmp_buf;
+ return QualType();
+ } else {
+ break;
+ }
+ } else {
+ Type = Context.getjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_jmp_buf;
+ return QualType();
+ } else {
+ break;
+ }
+ }
+ }
+ }
+</pre>
+</div>
+
+<p>It is better to write this something like:</p>
+
+<div class="doc_code">
+<pre>
+ case 'J':
+ if (Signed) {
+ Type = Context.getsigjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_sigjmp_buf;
+ return QualType();
+ }
+ } else {
+ Type = Context.getjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_jmp_buf;
+ return QualType();
+ }
+ }
+ break;
+</pre>
+</div>
+
+<p>Or better yet (in this case), as:</p>
+
+<div class="doc_code">
+<pre>
+ case 'J':
+ if (Signed)
+ Type = Context.getsigjmp_bufType();
+ else
+ Type = Context.getjmp_bufType();
+
+ if (Type.isNull()) {
+ Error = Signed ? ASTContext::GE_Missing_sigjmp_buf :
+ ASTContext::GE_Missing_jmp_buf;
+ return QualType();
+ }
+ break;
+</pre>
+</div>
+
+<p>The idea is to reduce indentation and the amount of code you have to keep
+ track of when reading the code.</p>
+
+</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<div class="doc_text">
<p>Use the "<tt>assert</tt>" function to its fullest. Check all of your
-preconditions and assumptions, you never know when a bug (not neccesarily even
+preconditions and assumptions, you never know when a bug (not necessarily even
yours) might be caught early by an assertion, which reduces debugging time
dramatically. The "<tt><cassert></tt>" header file is probably already
included by the header files you are using, so it doesn't cost anything to use
</ol>
<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>In addition, new code should always
-use <a href="#ll_raw_ostream"><tt>raw_ostream</tt></a> or
-the <tt>llvm::MemoryBuffer</tt> API (for reading in files).</p>
+example) is not problematic in this regard (just <tt><iostream></tt>).
+However, raw_ostream provides various APIs that are better performing for almost
+every use than std::ostream style APIs, so you should just use it for new
+code.</p>
+
+<p><b>New code should always
+use <a href="#ll_raw_ostream"><tt>raw_ostream</tt></a> for writing, or
+the <tt>llvm::MemoryBuffer</tt> API for reading files.</b></p>
</div>
projects / oota-llvm.git / blobdiff