diff --git a/llvm/docs/CodingStandards.html b/llvm/docs/CodingStandards.html index b04f4c53c865..21343ccbbd5f 100644 --- a/llvm/docs/CodingStandards.html +++ b/llvm/docs/CodingStandards.html @@ -122,6 +122,7 @@ should not be checked into CVS. Most source trees will probably have a standard file header format. The standard format for the LLVM source tree looks like this:

+
 //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
 // 
@@ -136,8 +137,8 @@ this:

 // base class for all of the VM instructions.
 //
 //===----------------------------------------------------------------------===//
-
+

A few things to note about this particular format: The "-*- C++ -*-" string on the first line is there to tell Emacs that the source file @@ -211,21 +212,22 @@ These nest properly and are better behaved in general than C style comments.

Immediately after the header file comment (and include guards if working on a header file), the minimal list of #includes required by the file should -be listed. We prefer these #includes to be listed in this order:

+href="#hl_dontinclude">minimal list of #includes required by the +file should be listed. We prefer these #includes to be listed in this +order:

  1. Main Module header
  2. Local/Private Headers
    3. -
  3. llvm/*
    4. -
  4. llvm/Analysis/*
    5. -
  5. llvm/Assembly/*
    6. -
  6. llvm/Bytecode/*
    7. -
  7. llvm/CodeGen/*
    8. +
  8. llvm/*
    9. +
  9. llvm/Analysis/*
    10. +
  10. llvm/Assembly/*
    11. +
  11. llvm/Bytecode/*
    12. +
  12. llvm/CodeGen/*
  13. ...
    14. -
  14. Support/*
    15. -
  15. Config/*
    16. -
  16. System #includes
    17. +
  17. Support/*
    18. +
  18. Config/*
    19. +
  19. System #includes

... and each catagory should be sorted by name.

@@ -315,22 +317,26 @@ a good thorough set of warnings, and stick to them. At least in the case of syntax of the code slightly. For example, an warning that annoys me occurs when I write code like this:

+
-  if (V = getValue()) {
-    ..
-  }
+if (V = getValue()) {
+  ...
+}
+

gcc will warn me that I probably want to use the == operator, and that I probably mistyped it. In most cases, I haven't, and I really don't want the spurious errors. To fix this particular problem, I rewrite the code like this:

+
-  if ((V = getValue())) {
-    ..
-  }
+if ((V = getValue())) {
+  ...
+}
+

...which shuts gcc up. Any gcc warning that annoys you can be fixed by massaging the code appropriately.

@@ -477,26 +483,30 @@ in the assertion statement (which is printed if the assertion is tripped). This helps the poor debugging make sense of why an assertion is being made and enforced, and hopefully what to do about it. Here is one complete example:

+
-  inline Value *getOperand(unsigned i) { 
-    assert(i < Operands.size() && "getOperand() out of range!");
-    return Operands[i]; 
-  }
+inline Value *getOperand(unsigned i) { 
+  assert(i < Operands.size() && "getOperand() out of range!");
+  return Operands[i]; 
+}
+

Here are some examples:

+
-  assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
 
-  assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
+assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
 
-  assert(idx < getNumSuccessors() && "Successor # out of range!");
+assert(idx < getNumSuccessors() && "Successor # out of range!");
 
-  assert(V1.getType() == V2.getType() && "Constant types must be identical!");
+assert(V1.getType() == V2.getType() && "Constant types must be identical!");
 
-  assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+

You get the idea...

@@ -510,9 +520,9 @@ enforced, and hopefully what to do about it. Here is one complete example:

-

Hard fast rule: Preincrement (++X) may be no slower than postincrement (X++) -and could very well be a lot faster than it. Use preincrementation whenever -possible.

+

Hard fast rule: Preincrement (++X) may be no slower than +postincrement (X++) and could very well be a lot faster than it. Use +preincrementation whenever possible.

The semantics of postincrement include making a copy of the value being incremented, returning it, and then preincrementing the "work value". For @@ -523,7 +533,6 @@ get in the habit of always using preincrement, and you won't have a problem.

-
Avoid std::endl @@ -535,13 +544,15 @@ get in the habit of always using preincrement, and you won't have a problem.

to the output stream specified. In addition to doing this, however, it also flushes the output stream. In other words, these are equivalent:

+
-  std::cout << std::endl;
-  std::cout << "\n" << std::flush;
+std::cout << std::endl;
+std::cout << '\n' << std::flush;
+

Most of the time, you probably have no reason to flush the output stream, so -it's better to use a literal "\n".

+it's better to use a literal '\n'.

@@ -552,11 +563,11 @@ it's better to use a literal "\n".

-

C++ is a powerful language. With a firm grasp on its capabilities, you can make -write effective, consise, readable and maintainable code all at the same time. -By staying consistent, you reduce the amount of special cases that need to be -remembered. Reducing the total number of lines of code you write is a good way -to avoid documentation, and avoid giving bugs a place to hide.

+

C++ is a powerful language. With a firm grasp on its capabilities, you can +make write effective, consise, readable and maintainable code all at the same +time. By staying consistent, you reduce the amount of special cases that need +to be remembered. Reducing the total number of lines of code you write is a +good way to avoid documentation, and avoid giving bugs a place to hide.

For these reasons, come to know and love the contents of your local <algorithm> header file. Know about <functional> and what it can do