From cafe0b4e1fec183f26e0ae374c09bad77388820a Mon Sep 17 00:00:00 2001 From: Zhanyong Wan Date: Tue, 23 Nov 2010 05:03:07 +0000 Subject: Fix formatting nits in the coding standards. Reviewed by clattner. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119998 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CodingStandards.html | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'docs') diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html index 22a2942..ff00c81 100644 --- a/docs/CodingStandards.html +++ b/docs/CodingStandards.html @@ -29,7 +29,7 @@
  • Treat Compiler Warnings Like Errors
  • Write Portable Code
    • -
  • Use of class/struct Keywords
    • +
  • Use of class/struct Keywords
  • Style Issues @@ -38,23 +38,23 @@
    1. A Public Header File is a Module
      2. -
    2. #include as Little as Possible
      3. +
    3. #include as Little as Possible
    4. Keep "internal" Headers Private
      5. -
    5. Use Early Exits and 'continue' to Simplify +
    6. Use Early Exits and continue to Simplify Code
      7. -
    7. Don't use "else" after a - return
      8. +
    8. Don't use else after a + return
    9. Turn Predicate Loops into Predicate Functions
  • The Low-Level Issues
    1. Assert Liberally
      2. -
    2. Do not use 'using namespace std'
      3. +
    3. Do not use 'using namespace std'
    4. Provide a virtual method anchor for classes in headers
      5. -
    5. Don't evaluate end() every time through a +
    6. Don't evaluate end() every time through a loop
    7. #include <iostream> is forbidden
      8. @@ -522,7 +522,7 @@ class itself... just make them private (or protected), and all is well.

      - Use Early Exits and 'continue' to Simplify Code + Use Early Exits and continue to Simplify Code
      @@ -531,7 +531,7 @@ class itself... just make them private (or protected), and all is well.

      decisions have to be remembered by the reader to understand a block of code. Aim to reduce indentation where possible when it doesn't make it more difficult to understand the code. One great way to do this is by making use of early -exits and the 'continue' keyword in long loops. As an example of using an early +exits and the continue keyword in long loops. As an example of using an early exit from a function, consider this "bad" code:

      @@ -623,7 +623,7 @@ structure the loop like this:

      This has all the benefits of using early exits from functions: it reduces nesting of the loop, it makes it easier to describe why the conditions are true, -and it makes it obvious to the reader that there is no "else" coming up that +and it makes it obvious to the reader that there is no else coming up that they have to push context into their brain for. If a loop is large, this can be a big understandability win.

      @@ -631,14 +631,14 @@ be a big understandability win.

      - Don't use "else" after a return + Don't use else after a return

      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 + 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":

      @@ -943,7 +943,7 @@ increasing link times.

      - Don't evaluate end() every time through a loop + Don't evaluate end() every time through a loop
      -- cgit v1.1