#include <iostream>

using namespace std;

class BST
{
public:
    BST()
    {
        i = 0;
    }
    int i;
};

class BalancedBST: public BST
{
private:
    int j;
};

void printBSTArray(ostream& out, const BST arr[], int numElements)
{
    for (int i = 0; i < numElements; i++)
    {
        out << arr[i].i << endl;
    }
}

int main()
{
    cout << "BST.\n";
    BST BSTArray[10];
    printBSTArray(cout, BSTArray, 10);

    cout << "BalancedBST.\n";
    BalancedBST bBSTArray[10];
    printBSTArray(cout, bBSTArray, 10);

    system("pause");

    return 0;
}

其結果如下：

 

 可以看到程序并不如我們所期望的那樣，這說明什么呢？
 arr[i],表示的是*（arr+i）,但是arr+i所指向的地址偏離arr所指向的地址是i*(an object in the array)。
因為參數被聲明為BST數組類型，那么數組的每個元素必須是BST，那么它們的間隔也畢定是i*sizeof(BST)。如果傳入BalancedBST數組，編譯器可能就會犯錯誤，在這種情況下，編譯器就會假定數組里每個對象的大小都和BST的大小一樣。而通常派生類要比基類有更多的成員變量，所以派生類一般都比基類對象大。所以我們就看到了如上的結果。

 試圖通過一個基類指針刪除一個包含派生類對象的數組，也會有同樣的問題。

所以不要把多臺應用到數組上，還是很有好處的。

去同學那玩，看到這么一本書《C++沉思錄》。這本書很早聽過，但是沒有讀過。于是捧起書讀了幾章，感覺很是不錯。其中第四章就是講“類設計者的核查表”。雖然用c++有幾年，但是有一些東西還是需要銘記于心的。

類設計者的核查表

一、        您的類需要一個構造函數么？

有些類太簡單，無需構造函數，但有些類太復雜，他們需要構造函數來隱藏它們的內部工作方式。

二、           您的數據成員是私有的么？

通常使用公有的數據成員不是什么好事，因為類設計者無法控制何時訪問這些成員。

三、           您的類需要一個無參的構造函數么？

如果一個類已經有了構造函數，想聲明該類的對象可以不必顯示地初始化它們，則必須顯示地寫一個無參的構造函數。

四、           是不是每一個構造函數初始化所有的數據成員？

構造函數的用途就是用一種明確定義的狀態來設置對象。對象的狀態由對象的數據成員進行反映。每個構造函數都要負責為所有的數據成員設置經過明確定義的值。

有時這種說法也未必總是正確的。有時，類會有一些數據成員，它們只在它們的對象存在了一定時間之后才有意義。提這個問題，只是激勵你進行思考。

五、           類需要構造函數么？

不是所有有構造函數的類都需要構造函數。如果深入考慮一個類要做些什么，那么該類是否需要析構函數的問題就十分明顯了。應該問一問該類是否分配了資源，而這些資源又不會有成員函數自動釋放，這就足夠了。特別是那些構造函數里包含了new表達式的類，通常要在析構函數中加上相應的delete表達式，所以需要一個虛析構函數。

六、        類需要一個虛析構函數么？

有些類需要虛析構函數只是為了聲明他們的析構函數是虛的。當然，決不會用做基類的類是不需要虛析構函數的：任何虛函數只在繼承的情況下才有用。

虛析構函數通常是空的。

七、           你的類需要復制構造函數么？

很多時候答案都是“不”，但是有時候答案是“是”。關鍵在于復制該類對象是否就相當于復制其數據成員和基類對象。如果并不相當，就需要復制構造函數。

如果你的類在構造函數內分配資源，則可能需要一個顯示的復制構造函數來管理資源。有析構函數的類通常是析構函數來釋放構造函數分配的資源，這通常說明需要一個復制構造函數。（空的虛析構函數除外）

如果不想用戶能夠復制該類的對象，就聲明復制構造函數為私有的。如果其他的成員不會使用這些成員函數，聲明就足夠了，沒有必要定義它們。

八、           你的類需要一個賦值操作么？

如果需要復制構造函數，同理多半也會需要一個賦值操作。

九、           你的賦值操作符能正確地將對象賦給對象本身么？

賦值總是用新值取代目標對象的舊值。如果原對象和目標對象是同一個，而我們又奉行“先釋放舊值，再復制”的行事規程，那么就可能在還沒有實施復制之前就把原對象銷毀了。

十、           你的類需要定義關系操作符么？

如果你的類邏輯上支持相等操作，那么提供operate== 和operate!=可能會有好處。類似的，如果你的類的值有某種排序關系，那就可能會想提供余下的關系操作符。只要它們想創建你的類型的有序集合，你就必須提供關系操作符。

十一  刪除數組時你記住了用delete[]么？

這個形式的存在，是C++希望在保持與C的兼容性的同時關注效率。C++要求用戶告知要被刪除的是不是數組。如果是，該實現就可能會提供另一個地方來存儲長度，因為與數組所需的內存量相比，這個常數的開銷會小很多。

十二   記得在復制構造函數和賦值操作符的參數類型中加上了const么？

復制構造函數應該是像X::X(const X&)這樣，畢竟復制對象不會改變原對象。實際上，由于綁定一個非const引用到一個臨時對象是非法的，使用X::X(X&)作為復制構造函數不會允許復制任何特殊表達式的結果。同樣道理適用于賦值。

十三   如果函數有引用參數，它們應該是const引用么？

只有當函數想改變參數時，它才應該有不用const聲明的引用參數。

        計算階段由構造函數體內的所有語句構成。在計算階段中，數據成員的設置被認為是賦值，而不是初始化。

使用初始化列表有兩個原因：

1.必須這樣做：

        三種情況下需要使用初始化成員列表
        1）對象成員；
        2）const修飾的成員；
        3）引用成員數據；

(1)如果有一個類成員，它本身是一個類或者是一個結構，而且這個成員它只有一個帶參數的構造函數，而沒有默認構造函數，這時要對這個類成員進行初始化，就必須調用這個類成員的帶參數的構造函數，如果沒有初始化列表，那么他將無法完成第一步，就會報錯。

using namespace std;
class ABC
{
public:
    ABC(int x,int y,int z):a(x),b(y),c(z){};
private:
  int a;
    int b;
    int c;
};
class MyClass
{
public:
    MyClass(int a,int b,int c):abc(a,b,c){}
private:
    ABC abc;
};

int main()
{
    MyClass o(1,2,3);
    return 0;
}

(2)當類成員中含有一個const成員時

(3)當類成員中含有一個引用時

#include<iostream>
using namespace std;

class ConstRef {
public:
    ConstRef(int i);
    void print();
private:
    int a;
    const int b;//const成員
    int &c;//引用
};

ConstRef::ConstRef(int i):b(i),c(a)//含有一個const對象時，或者是一個引用時使用初始化成員列表
{
    a = i;       // ok
    //b = i;         // 錯誤
    //c = a;       // 錯誤
}
void ConstRef::print()
{
    cout<<a<<endl;
    cout<<b<<endl;
    cout<<c<<endl;
}
int main()
{
    ConstRef o(1);
    o.print();
    return 0;
}

2.效率要求這樣做：

類對象的構造順序顯示，進入構造函數體后，進行的是計算，是對他們的賦值操作，顯然，賦值和初始化是不同的，這樣就體現出了效率差異，如果不用成員初始化列表，那么類對自己的類成員分別進行的是一次隱式的默認構造函數的調用，和一次復制操作符的調用，如果是類對象，這樣做效率就得不到保障。

注意：構造函數需要初始化的數據成員，不論是否顯式的出現在構造函數的成員初始化列表中，都會在該處完成初始化，并且初始化的順序和其在聲明時的順序是一致的，與列表的先后順序無關，所以要特別注意，保證兩者順序一致才能真正保證其效率。

現在明白為什么要使用成員初始化列表了。

這里再強調一下類的初始化的順序，應該是類成員變量的初始化不是按照初始化表的順序被初始化的，而是按照在類中聲明的順序被初始化的。
這是摘自：Effective C++學習筆記：初始化列表中成員列出的順序和它們在類中聲明的順序相同 http://www.shnenglu.com/xczhang/archive/2008/01/22/41613.html

為什么會這樣呢？我們知道，對一個對象的所有成員來說，它們的析構函數被調用的順序總是和它們在構造函數里被創建的順序相反。那么，如果允許上面的情況（即，成員按它們在初始化列表上出現的順序被初始化）發生，編譯器就要為每一個對象跟蹤其成員初始化的順序，以保證它們的析構函數以正確的順序被調用。這會帶來昂貴的開銷。所以，為了避免這一開銷，同一種類型的所有對象在創建（構造）和摧毀（析構）過程中對成員的處理順序都是相同的,而不管成員在初始化列表中的順序如何。

注意：上述內容不適用于static變量，static變量應該在類的構造函數前被初始化。

好文章拿來學習，請作者見諒哈！

    以下為引用：

 // Global variable
 CRITICAL_SECTION CriticalSection;

 void main()
 {
     ...

     // Initialize the critical section one time only.
     if (!InitializeCriticalSectionAndSpinCount(&CriticalSection, 0x80000400) )
         return;
     ...

     // Release resources used by the critical section object.
     DeleteCriticalSection(&CriticalSection)
 }

 DWORD WINAPI ThreadProc( LPVOID lpParameter )
 {
     ...

     // Request ownership of the critical section.
     EnterCriticalSection(&CriticalSection);

     // Access the shared resource.

     // Release ownership of the critical section.
     LeaveCriticalSection(&CriticalSection);

     ...
 }

     首先看看構造和析構臨界區結構的函數。
     InitializeCriticalSection 函數(ntosdll esource.c:1210)實際上是調用 InitializeCriticalSectionAndSpinCount 函數(resource.c:1266)完成功能的，只不過傳入一個值為0的初始Spin計數器；InitializeCriticalSectionAndSpinCount 函數主要完成兩部分工作：初始化 RTL_CRITICAL_SECTION 結構和 RTL_CRITICAL_SECTION_DEBUG 結構。前者是臨界區的核心結構，下面將著重討論；后者是調試用結構，Matt 那篇文章里面分析的很清楚了，我這兒就不羅嗦了 :P
     RTL_CRITICAL_SECTION結構在winnt.h中定義如下：

以下為引用：

 typedef struct _RTL_CRITICAL_SECTION {
     PRTL_CRITICAL_SECTION_DEBUG DebugInfo;

     //
     //  The following three fields control entering and exiting the critical
     //  section for the resource
     //

     LONG LockCount;
     LONG RecursionCount;
     HANDLE OwningThread;        // from the thread''s

ClientId->UniqueThread
     HANDLE LockSemaphore;
     ULONG_PTR SpinCount;        // force size on 64-bit systems when packed
 } RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;

     InitializeCriticalSectionAndSpinCount 函數中首先對臨界區結構進行了初始化

     DebugInfo 字段指向初始化臨界區時分配的RTL_CRITICAL_SECTION_DEBUG結構；
     LockCount 字段是臨界區中最重要的字段，初始值為-1，當臨界區被獲取(Hold)時此字段大于等于0；
     RecursionCount 字段保存當前臨界區所有者線程的獲取緩沖區嵌套層數，初始值為0；
     OwningThread 字段保存當前臨界區所有者線程的句柄，初始值為0；
     LockSemaphore 字段實際上是一個auto-reset的事件句柄，用于喚醒等待獲取臨界區的阻塞線程，初始值為0；
     SpinCount 字段用于在多處理器環境下完成輕量級的CPU見同步，單處理器時沒有使用（初始值為0），多處理器時設置為SpinCount參數值（最大為MAX_SPIN_COUNT=0x00ffffff）。此外 RtlSetCriticalSectionSpinCount 函數(resource.c:1374)的代碼與這兒設置SpinCount的代碼完全一樣。

     初始化臨界區結構后，函數會根據SpinCount參數的一個標志位判斷是否需要預先初始化 LockSemaphore 字段，如果需要則使用NtCreateEvent創建一個具有訪問權限的同步用事件核心對象，初始狀態為沒有激發。這一初始化本來是在 EnterCriticalSection 函數中完成的，將之顯式提前可以進一步優化 EnterCriticalSection 函數的性能。
     值得注意的是，這一特性僅對Win2k有效。MSDN里面說明如下：

以下為引用：

 Windows 2000:  If the high-order bit is set, the function preallocates the event used by the EnterCriticalSection function. Do not set this bit if you are creating a large number of critical section objects, because it will consume a significant amount of nonpaged pool. This flag is not necessary on Windows XP and later, and it is ignored.

     與之對應的 DeleteCriticalSection 函數完成關閉事件句柄和是否調試結構的功能。

     臨界區真正的核心代碼在win2kprivate tosdlli386critsect.asm里面，包括_RtlEnterCriticalSection、_RtlTryEnterCriticalSection和_RtlLeaveCriticalSection三個函數。

     _RtlEnterCriticalSection 函數 (critsect.asm:85) 首先檢查SpinCount是否為0，如果不為0則處理多處理器架構下的問題[分支1]；如為0則使用原子操作給LockCount加一，并判斷是否其值為0。如果加一后LockCount大于0，則此臨界區已經被獲取[分支2]；如為0則獲取當前線程TEB中的線程句柄，保存在臨界區的OwningThread字段中，并將RecursionCount設置為1。調試版本則調用RtlpCriticalSectionIsOwned函數在調試模式下驗證此緩沖區是被當前線程獲取的，否則在調試模式下激活調試器。最后還會更新TEB的CountOfOwnedCriticalSections計數器，以及臨界區調試結構中的EntryCount字段。
     如果此臨界區已經被獲取[分支2]，則判斷獲取臨界區的線程句柄是否與當前線程相符。如果是同一線程則直接將RecursionCount和調試結構的EntryCount字段加一；如果不是當前線程，則調用RtlpWaitForCriticalSection函數等待此臨界區，并從頭開始執行獲取臨界區的程序。
     多CPU情況的分支處理方式類似，只是多了對SpinCount的雙重檢查處理。

     接著的_RtlTryEnterCriticalSection(critsect.asm:343)函數是一個輕量級的嘗試獲取臨界區的函數。偽代碼如下：

以下為引用：

 if(CriticalSection->LockCount == -1)
 {
   // 臨界區可用
   CriticalSection->LockCount = 0;
   CriticalSection->OwningThread = TEB->ClientID;
   CriticalSection->RecursionCount = 1;

   return TRUE;
 }
 else
 {
   if(CriticalSection->OwningThread == TEB->ClientID)
   {
     // 臨界區是當前線程獲取
     CriticalSection->LockCount++;
     CriticalSection->RecursionCount++;

     return TRUE;
   }
   else
   {
     // 臨界區已被其它線程獲取
     return FALSE;
   }
 }
 
 

     最后的_RtlLeaveCriticalSection(critsect.asm:271)函數釋放已獲取的臨界區，實現就比較簡單了，實際上就是對嵌套計數器和鎖定計數器進行操作。偽代碼如下：

以下為引用：

 if(--CriticalSection->RecursionCount == 0)
 {
bsp;  // 臨界區已不再被使用
   CriticalSection->OwningThread = 0;
 

   if(--CriticalSection->LockCount)
   {
     // 仍有線程鎖定在臨界區上
     _RtlpUnWaitCriticalSection(CriticalSection)
   }
 }
 else
 {
   --CriticalSection->LockCount
 }

        一般用法：使用“#”把宏參數變為一個字符串，用”##”把兩個宏參數結合在一起

       例子：

#include <iostream>
using namespace std;

#define TEST1(x) (cout<<id##x<<endl);
#define TEST2(p) (cout<<#p<<endl);
int main()
{
    int id1 = 1001;
    int id2 = 1002;
    TEST1(1);    // == cout<< id1 << endl;
    TEST2(2);    // == cout<< "2" << endl;
    TEST1(2);    // == cout<< id2 << endl;

    system("pause");
    return 0;
}

1.引言
C++語言的創建初衷是“a better C”，但是這并不意味著C++中類似C語言的全局變量和函數所采用的編譯和連接方式與C語言完全相同。作為一種欲與C兼容的語言，C++保留了一部分過程式語言的特點（被世人稱為“不徹底地面向對象”），因而它可以定義不屬于任何類的全局變量和函數。但是，C++畢竟是一種面向對象的程序設計語言，為了支持函數的重載，C++對全局函數的處理方式與C有明顯的不同。
2.從標準頭文件說起

某企業曾經給出如下的一道面試題：
面試題:為什么標準頭文件都有類似以下的結構？
#ifndef __INCvxWorksh
#define __INCvxWorksh
#ifdef __cplusplus
extern "C" {
#endif
/*...*/
#ifdef __cplusplus
}
#endif
#endif /* __INCvxWorksh */
分析
顯然，頭文件中的編譯宏“#ifndef __INCvxWorksh、#define __INCvxWorksh、#endif” 的作用是防止該頭文件被重復引用。
那么
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
的作用又是什么呢？我們將在下文一一道來。

3.深層揭密extern "C"

extern "C" 包含雙重含義，從字面上即可得到：首先，被它修飾的目標是“extern”的；其次，被它修飾的目標是“C”的。讓我們來詳細解讀這兩重含義。
被extern "C"限定的函數或變量是extern類型的；
extern是C/C++語言中表明函數和全局變量作用范圍（可見性）的關鍵字，該關鍵字告訴編譯器，其聲明的函數和變量可以在本模塊或其它模塊中使用。記住，下列語句：
extern int a;
僅僅是一個變量的聲明，其并不是在定義變量a，并未為a分配內存空間。變量a在所有模塊中作為一種全局變量只能被定義一次，否則會出現連接錯誤。
通常，在模塊的頭文件中對本模塊提供給其它模塊引用的函數和全局變量以關鍵字extern聲明。例如，如果模塊B欲引用該模塊A中定義的全局變量和函數時只需包含模塊A的頭文件即可。這樣，模塊B中調用模塊A中的函數時，在編譯階段，模塊B雖然找不到該函數，但是并不會報錯；它會在連接階段中從模塊A編譯生成的目標代碼中找到此函數。
與extern對應的關鍵字是static，被它修飾的全局變量和函數只能在本模塊中使用。因此，一個函數或變量只可能被本模塊使用時，其不可能被extern “C”修飾。
被extern "C"修飾的變量和函數是按照C語言方式編譯和連接的；
未加extern “C”聲明時的編譯方式
首先看看C++中對類似C的函數是怎樣編譯的。
作為一種面向對象的語言，C++支持函數重載，而過程式語言C則不支持。函數被C++編譯后在符號庫中的名字與C語言的不同。例如，假設某個函數的原型為：
void foo( int x, int y );
該函數被C編譯器編譯后在符號庫中的名字為_foo，而C++編譯器則會產生像_foo_int_int之類的名字（不同的編譯器可能生成的名字不同，但是都采用了相同的機制，生成的新名字稱為“mangled name”）。
foo_int_int這樣的名字包含了函數名、函數參數數量及類型信息，C++就是靠這種機制來實現函數重載的。例如，在C++中，函數void foo( int x, int y )與void foo( int x, float y )編譯生成的符號是不相同的，后者為_foo_int_float。

同樣地，C++中的變量除支持局部變量外，還支持類成員變量和全局變量。用戶所編寫程序的類成員變量可能與全局變量同名，我們以"."來區分。而本質上，編譯器在進行編譯時，與函數的處理相似，也為類中的變量取了一個獨一無二的名字，這個名字與用戶程序中同名的全局變量名字不同。
未加extern "C"聲明時的連接方式
假設在C++中，模塊A的頭文件如下：
// 模塊A頭文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
int foo( int x, int y );
#endif
在模塊B中引用該函數：
// 模塊B實現文件　moduleB.cpp
#include "moduleA.h"
foo(2,3);

實際上，在連接階段，連接器會從模塊A生成的目標文件moduleA.obj中尋找_foo_int_int這樣的符號！
加extern "C"聲明后的編譯和連接方式
加extern "C"聲明后，模塊A的頭文件變為：
// 模塊A頭文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
extern "C" int foo( int x, int y );
#endif
在模塊B的實現文件中仍然調用foo( 2,3 )，其結果是：
（1）模塊A編譯生成foo的目標代碼時，沒有對其名字進行特殊處理，采用了C語言的方式；
（2）連接器在為模塊B的目標代碼尋找foo(2,3)調用時，尋找的是未經修改的符號名_foo。
如果在模塊A中函數聲明了foo為extern "C"類型，而模塊B中包含的是extern int foo( int x, int y ) ，則模塊B找不到模塊A中的函數；反之亦然。
所以，可以用一句話概括extern “C”這個聲明的真實目的（任何語言中的任何語法特性的誕生都不是隨意而為的，來源于真實世界的需求驅動。我們在思考問題時，不能只停留在這個語言是怎么做的，還要問一問它為什么要這么做，動機是什么，這樣我們可以更深入地理解許多問題）：
實現C++與C及其它語言的混合編程。

明白了C++中extern "C"的設立動機，我們下面來具體分析extern "C"通常的使用技巧。

4.extern "C"的慣用法
（1）在C++中引用C語言中的函數和變量，在包含C語言頭文件（假設為cExample.h）時，需進行下列處理：
extern "C"
{
#include "cExample.h"
}
而在C語言的頭文件中，對其外部函數只能指定為extern類型，C語言中不支持extern "C"聲明，在.c文件中包含了extern "C"時會出現編譯語法錯誤。
筆者編寫的C++引用C函數例子工程中包含的三個文件的源代碼如下：
/* c語言頭文件：cExample.h */
#ifndef C_EXAMPLE_H
#define C_EXAMPLE_H
extern int add(int x,int y);
#endif
/* c語言實現文件：cExample.c */
#include "cExample.h"
int add( int x, int y )
{
return x + y;
}
// c++實現文件，調用add：cppFile.cpp
extern "C"
{
#include "cExample.h"
}
int main(int argc, char* argv[])
{
add(2,3);
return 0;
}
如果C++調用一個C語言編寫的.DLL時，當包括.DLL的頭文件或聲明接口函數時，應加extern "C" {　}。
（2）在C中引用C++語言中的函數和變量時，C++的頭文件需添加extern "C"，但是在C語言中不能直接引用聲明了extern "C"的該頭文件，應該僅將C文件中將C++中定義的extern "C"函數聲明為extern類型。

筆者編寫的C引用C++函數例子工程中包含的三個文件的源代碼如下：
//C++頭文件 cppExample.h
#ifndef CPP_EXAMPLE_H
#define CPP_EXAMPLE_H
extern "C" int add( int x, int y );
#endif
//C++實現文件 cppExample.cpp
#include "cppExample.h"
int add( int x, int y )
{
return x + y;
}
/* C實現文件 cFile.c
/* 這樣會編譯出錯：#include "cExample.h" */
extern int add( int x, int y );
int main( int argc, char* argv[] )
{
add( 2, 3 );
return 0;
}
如果深入理解了第3節中所闡述的extern "C"在編譯和連接階段發揮的作用，就能真正理解本節所闡述的從C++引用C函數和C引用C++函數的慣用法。

作者：José M. Aguilar（西班牙語）
英文譯者：Timm Martin
中文譯者：numenzq

下面的13個技巧向你展示如何添加代碼注釋，這些技巧都很容易理解和記憶。

1. 逐層注釋
為每個代碼塊添加注釋，并在每一層使用統一的注釋方法和風格。例如：
針對每個類：包括摘要信息、作者信息、以及最近修改日期等
針對每個方法：包括用途、功能、參數和返回值等
在團隊工作中，采用標準化的注釋尤為重要。當然，使用注釋規范和工具（例如C#里的XML，Java里的Javadoc）可以更好的推動注釋工作完成得更好。
2. 使用分段注釋
如果有多個代碼塊，而每個代碼塊完成一個單一任務，則在每個代碼塊前添加一個注釋來向讀者說明這段代碼的功能。例子如下：

// Check that all data records
// are correct
foreach (Record record in records)
{
if (rec.checkStatus()==Status.OK)
{
. . .
}
}
// Now we begin to perform
// transactions
Context ctx = new ApplicationContext();
ctx.BeginTransaction();
. . .

3. 在代碼行后添加注釋
如果多行代碼的每行都要添加注釋，則在每行代碼后添加該行的注釋，這將很容易理解。例如：

const MAX_ITEMS = 10; // maximum number of packets
const MASK = 0x1F;    // mask bit TCP

在分隔代碼和注釋時，有的開發者使用tab鍵，而另一些則使用空格鍵。然而由于tab鍵在各編輯器和IDE工具之間的表現不一致，因此最好的方法還是使用空格鍵。

4. 不要侮辱讀者的智慧

避免以下顯而易見的注釋：

if (a == 5)      // if a equals 5
counter = 0; // set the counter to zero

寫這些無用的注釋會浪費你的時間，并將轉移讀者對該代碼細節的理解。

5. 禮貌點
避免粗魯的注釋，如：“注意，愚蠢的使用者才會輸入一個負數”或“剛修復的這個問題出于最初的無能開發者之手”。這樣的注釋能夠反映到它的作者是多么的拙劣，你也永遠不知道誰將會閱讀這些注釋，可能是：你的老板，客戶，或者是你剛才侮辱過的無能開發者。

6. 關注要點

不要寫過多的需要轉意且不易理解的注釋。避免ASCII藝術，搞笑，詩情畫意，hyperverbosity的注釋。簡而言之，保持注釋簡單直接。

7. 使用一致的注釋風格
一些人堅信注釋應該寫到能被非編程者理解的程度。而其他的人則認為注釋只要能 被開發人員理解就行了。無論如何，Successful Strategies for Commenting Code已經規定和闡述了注釋的一致性和針對的讀者。就個人而言，我懷疑大部分非編程人員將會去閱讀代碼，因此注釋應該是針對其他的開發者而言。

8. 使用特有的標簽
在一個團隊工作中工作時，為了便于與其它程序員溝通，應該采用一致的標簽集進行注釋。例如，在很多團隊中用TODO標簽表示該代碼段還需要額外的工作。

int Estimate(int x, int y)
{
// TODO: implement the calculations
return 0;
}

注釋標簽切忌不要用于解釋代碼，它只是引起注意或傳遞信息。如果你使用這個技巧，記得追蹤并確認這些信息所表示的是什么。

9. 在代碼時添加注釋
在寫代碼時就添加注釋，這時在你腦海里的是清晰完整的思路。如果在代碼最后再添 加同樣注釋，它將多花費你一倍的時間。而“我沒有時間寫注釋”，“我很忙”和“項目已經延期了”這都是不愿寫注釋而找的借口。一些開發者覺得應該 write comments before code，用于理清頭緒。例如：
public void ProcessOrder()
{
// Make sure the products are available
// Check that the customer is valid
// Send the order to the store
// Generate bill
}

10. 為自己注釋代碼

當注釋代碼時，要考慮到不僅將來維護你代碼的開發人員要看，而且你自己也可能要看。用Phil Haack大師的話來說就是：“一旦一行代碼顯示屏幕上，你也就成了這段代碼的維護者”。因此，對于我們寫得好（差）的注釋而言，我們將是第一個受益者（受害者）。

11. 同時更新代碼和注釋

如果注釋沒有跟隨代碼的變化而變化，及時是正確的注釋也沒有用。代碼和注釋應該同步變化，否則這樣的注釋將對維護你代碼的開發者帶來更大的困難。使用重構工具時應特別注意，它只會自動更新代碼而不會修改注釋，因此應該立即停止使用重構工具。

12. 注釋的黃金規則：易讀的代碼
對于開發者的一個基本原則就是：讓你的代碼為己解釋。雖然有些人懷疑這會讓那些不愿意寫注釋的開發者鉆空子，不過這樣的代碼真的會使你容易理解，還不需要額外維護注釋。例如在Fluid Interfaces文章里向你展示的代碼一樣：

Calculator calc = new Calculator();
calc.Set(0);
calc.Add(10);
calc.Multiply(2);
calc.Subtract(4);
Console.WriteLine( "Result: {0}", calc.Get() );

在這個例子中，注釋是不需要的，否則可能就違反了技巧4。為了使代碼更容易理解，你可以考慮使用適當的名字 （Ottinger's Rules里講解得相當好），確保正確的縮進，并且采用coding style guides，違背這個技巧可能的結果就像是注釋在為不好的代碼apologize。

13. 與同事分享技巧
雖然技巧10已經向我們表明了我們是如何從好的注釋中直接受益，這些技巧將讓所有開發者受益，特別是團隊中一起工作的同事。因此，為了編寫出更容易理解和維護的代碼，嘗試自由的和你的同事分享這些注釋技巧。

下面摘自http://www.shnenglu.com/woaidongmao/archive/2008/11/03/65897.html

看到他們的在爭論很有意思，我不是很懂。

有利還是有弊呢？

EXT_ASSERT將ASSERT與if結合在一起

posted on 2008-11-03 23:34 肥仔 閱讀(333) 評論(7)  編輯 收藏 引用 所屬分類: C++存檔