From 91d64afebd0c8a773a912edb692ef5b6f7ef3f36 Mon Sep 17 00:00:00 2001 From: Misha Brukman Date: Tue, 26 Oct 2004 16:18:43 +0000 Subject: [PATCH] Use around "#include" and "std::endl" git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17258 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CodingStandards.html | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html index 0073e427721..b5946a42284 100644 --- a/docs/CodingStandards.html +++ b/docs/CodingStandards.html @@ -19,7 +19,7 @@
  1. Commenting
  2. Comment Formatting
  3. -
  4. #include Style
  5. +
  6. #include Style
  7. Source Code Width
  8. Use Spaces Instead of Tabs
  9. Indent Code Consistently
  10. @@ -46,7 +46,7 @@
    1. Assert Liberally
    2. Prefer Preincrement
    3. -
    4. Avoid std::endl
    5. +
    6. Avoid std::endl
    7. Exploit C++ to its Fullest
@@ -195,7 +195,8 @@ when it is useful to use C style (/* */) comments however:

  1. When writing a C code: Obviously if you are writing C code, use C style comments. :)
  2. -
  3. When writing a header file that may be #included by a C source file.
  4. +
  5. When writing a header file that may be #included by a C source + file.
  6. When writing a source file that is used by a tool that only accepts C style comments.
@@ -207,7 +208,7 @@ These nest properly and are better behaved in general than C style comments.

@@ -235,13 +236,13 @@ order:

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

The "Main Module Header" file applies to .cpp file -which implement an interface defined by a .h file. This #include should always -be included first regardless of where it lives on the file system. By -including a header file first in the .cpp files that implement the interfaces, -we ensure that the header does not have any hidden dependencies which are not -explicitly #included in the header, but should be. It is also a form of -documentation in the .cpp file to indicate where the interfaces it implements -are defined.

+which implement an interface defined by a .h file. This #include +should always be included first regardless of where it lives on the file +system. By including a header file first in the .cpp files that implement the +interfaces, we ensure that the header does not have any hidden dependencies +which are not explicitly #included in the header, but should be. It is also a +form of documentation in the .cpp file to indicate where the interfaces it +implements are defined.

@@ -432,7 +433,7 @@ translation unit.

@@ -441,13 +442,13 @@ translation unit.

have to, especially in header files.

But wait, sometimes you need to have the definition of a class to use it, or -to inherit from it. In these cases go ahead and #include that header file. Be -aware however that there are many cases where you don't need to have the full -definition of a class. If you are using a pointer or reference to a class, you -don't need the header file. If you are simply returning a class instance from a -prototyped function or method, you don't need it. In fact, for most cases, you -simply don't need the definition of a class... and not #include'ing -speeds up compilation.

+to inherit from it. In these cases go ahead and #include that header +file. Be aware however that there are many cases where you don't need to have +the full definition of a class. If you are using a pointer or reference to a +class, you don't need the header file. If you are simply returning a class +instance from a prototyped function or method, you don't need it. In fact, for +most cases, you simply don't need the definition of a class... and not +#include'ing speeds up compilation.

It is easy to try to go too overboard on this recommendation, however. You must include all of the header files that you are using, either directly @@ -557,7 +558,7 @@ get in the habit of always using preincrement, and you won't have a problem.

-- 2.11.0