是否有良好的/廣泛採用的C++模板編碼慣例/標準？

我喜歡編碼標準。編寫C++時，我喜歡編碼標準。一個好的編碼標準爲語言增加了上下文，使得解析起來更加容易一些。是否有良好的/廣泛採用的C++模板編碼慣例/標準？

有，我認爲每個人都至少有點熟悉的幾個普遍實行的標準：以「M」或「M_」

類前綴前綴

成員變量（一般項目的具體，即在Qt中，所有類名都以'Q'爲前綴）
包含守護約定，例如「取所有大寫的文件名，替換'。用「_」「
三個

規則有很多這樣的小C++規則。不幸的是，我從來沒有設法找到與模板相關的指導。我認爲模板參數最流行的名稱是'T'，但它沒有意義，除非模板很明顯，否則可能會使代碼更難以閱讀。

無論如何，我的核心問題是模板很難閱讀，我認爲可以使用一些約定來使它們更易於閱讀。有誰知道一個廣泛應用的約定，使模板化的代碼更容易閱讀？

來源

2011-02-22 Dan O

您是否閱讀過Herb Sutter和Andrei Alexandrescu編寫的* C++編碼標準：101規則，指南和最佳實踐*正如你可能用Andrei作爲共同作者猜測的那樣，它至少在極少數情況下提到模板一次...... :-) –

我還沒有讀過，聽起來很有趣。爲什麼你的評論不是一個答案，順便說一句？僅僅因爲這不是你的原創作品？ –

剛剛加入我的鹽糧。我認爲C++編程領域中最重要的兩個庫是標準模板庫和Boost庫。我個人嘗試主要遵循這些圖書館中主要的表示法。也就是說，對於模板參數，類，函數，數據成員，typedefs，枚舉等以及CamelCase（沒有下劃線分隔）的下劃線分隔的小寫名稱。通常情況下，您還希望模板參數具有明智的名稱。一個好的做法是爲他們提供他們應該實現的概念的名稱（例如，應該是實現ForwardIteratorConcept的迭代器的模板參數應該被命名爲ForwardIterator）。

您提到的約定（「m」代表成員，大寫字母開頭的名稱）是一種純粹的面向對象編程約定（「純」意思是：沒有任何其他編程範例像通用編程或模板元編程）。它主要用於Java（或由編程C++的Java「本地人」）。我個人不喜歡它，知道很少有人這樣做。在採用這種表示法的框架或項目中工作時，我總是感到有些惱火，它使得標準庫，增強庫以及名稱空間的整體正確用法變得無趣。

來源

2011-02-22 05:50:40

好帖子，沒有諷刺或誤導，只是兩個主要玩家似乎支持的模式的一個很好的總結。 –

不過，我想指出的是，有些人喜歡m前綴的原因不是爲了避免名稱衝突，而是爲了將上下文添加到C++中，這是出乎意料地上下文無關的。在處理將被許多其他人讀取的代碼時，我看到它的好處。 –

@丹O，我同意，我也使用領先的m在這裏和那裏，特別是如果我正在寫一個「大」類。所以，我同意，當需要這種幫助時，有助於提供背景。但大多數情況下，我試圖支持「更小」，更獨立的課程，其中背景很小且毫不含糊，但這並非總是可行。 –

*與 'M' 或 'M_'

可疑前綴的成員變量。

*類前綴（一般項目的具體，即Qt的所有類名與 'Q' 爲前綴）

可怕。需要練習回來。

Big three並不是一個真正的標準，並且作爲Big Two的一個很好的實踐已經被超越了（因爲使用RAII作爲指針否定了析構函數的必要性，即使您需要Copy ctr和assignment也是如此）。

無論如何...

你需要區分你的模板參數和普通的代碼。因此，您應該使用您在模板參數的標準代碼中未使用的命名約定。一個很好的方法是使用CamelCase模板參數。另一個重要的方面是，由於C++根本不強制實現概念，所以要根據他們期望的概念命名參數。 ForwardIter因此爲參數提供了一個好的參數名稱，而不是一個前向迭代器。

當然，如果您已經使用CamelCase作爲您的類名（Java程序員 - blech：p），那麼您應該使用別的東西。

當你進入複雜的實例化等等，那麼你需要使用一些方法來在多行中聲明你的模板實例。當元編程時，您還經常需要將事物分成多行和/或多個類型/模板。這是學習你的東西之一。我喜歡以下方法：

template < typename MyParams > 
struct my_metafunction 
    : mpl::if_ 
    < 
     check // probably wouldn't actually split this one since it's trivial...but as example... 
     < 
     MyParams 
     > 
    , some_type_expression 
    , some_other_type_expression 
    > 
{};

來源

2011-02-22 04:55:10

名稱沒有「通用約定」。即使你提到的慣例並不像你想象的那麼普遍。我想不出任何人使用m或m_前綴作爲Windows開發人員子集以外的類成員數據。類似的用於爲類名加前綴。

這種約定非常針對項目。你在一個項目中同意他們，然後繼續。當你開始一個新的項目時，如果你願意的話，可以有新的約定。如果你缺乏想象力或信心挑選自己的會議，那麼購買Herb Sutter和Andrei Alexandrescu的書C++ Coding Standards。事實上，你應該閱讀它，因爲它處理比命名約定更有效的約定。事情真的很重要。

如果完全有幫助，我有時會看到人們選擇以大寫字母開頭的模板參數短名稱。例如，template<class Ch, class Tr>。查看你的編譯器的標準庫以獲取靈感。

來源

2011-02-22 05:01:56 wilhelmtell

大聲笑，我不認爲我曾經從STL實現中的可讀性角度找到一個好主意...... –

stdlib代碼很難閱讀，因爲他們必須做的所有__和其他廢話從跺腳用戶代碼。 –

@CrazyEddie我認爲雙下劃線由常規和歷史支持而不是基本原理，因爲標準名稱位於'std'名稱空間中。當然，除了沒有範圍的宏之外。 – wilhelmtell

如果你想看看他們的編碼約定，請看Boost。

來源

2011-02-22 05:14:54 Marlon

大聲笑，我想我終於找到了一個純粹的C++問題，不會被一句話和一個提升的鏈接回答。 –

@Marlon，如果你只是提供一個鏈接到首頁的提升，你可能已經發布了google.com的鏈接，也就是說根本沒有回答。 – Catskul

@Catskul，似乎在downvote按鈕上有點自由。我認爲downvotes是誤導性的信息！無論如何，我敢肯定，如果你花時間瀏覽本網站，你會發現成千上萬的答案，只有一個鏈接到網站的首頁。 Boost也不例外。乾杯! – Marlon

像其他人一樣，這取決於項目編碼風格。我喜歡在編碼時使用小寫字母與分數下分開。而爲了和諧我也使用小寫字母作爲模板參數。爲了區分他們，我從下劃線開始，以「_t」結尾。

template<typename _encoder_t> 
class compression 
{ 
typedef typename _encoder_t::settings settings_t; 
... 
};

來源

2011-02-22 05:33:42 msh

C++標準17.4.3.1.2規定：「以下劃線開頭的每個名稱都保留給實現以用作全局名稱空間中的名稱。」我認爲你應該改變模板參數的命名約定。它在C++中不是「合法」的。 –

@Mikael（Nitpick :)實際上@msh命名，因爲他描述它是合法的，因爲模板參數不在全局名稱空間中。但我仍然不會使用任何以下劃線開頭的標識符。 –

謝謝你們的關心。我將使用沒有下劃線。 – msh

我的建議是總是看一個語言的標準庫，以設置一個編碼約定的例子。其結果是您的代碼將更自然地閱讀它所編寫的語言。基本上，編寫看起來可以成爲ISO C++文檔一部分的C++。

對於C++，標準容器，迭代器和算法有許多可用作示例的模板。

作爲一個反例，使用camel case會讓你的C++代碼像Java一樣讀取。當你最終將標準庫中的東西放在自己的代碼中時，它會顯得很奇怪。

也就是說，有兩個例外需要考慮。首先，如果您已經擁有龐大的代碼庫，請遵循已有的代碼：混合的樣式很混亂。其次，有很多優秀的庫，如Qt，不遵循標準庫的風格，它們也是值得作爲編碼標準的例子。

來源

2011-02-22 06:10:10 smithco

再一次，STL得到了噓聲。在我的機器上，這裏是如何聲明std :: vector：template > class vector ...誰知道符號中的_Tp的含義和_是否正在玩火。我認爲即使它們是很好的實現，stl也不是很棒的「如何編寫出色的模板」。 –

另外@Dan說，請注意，標準庫使用保留的標識符名稱。即如上所述使用'_Alloc'或'_Tp'在用戶代碼中是不合法的。 –

是的，標準庫實現有意使用前導下劃線的約定來防止用戶代碼中的衝突。雖然，該標準聲明一個向量爲「模板>類向量」。_Alloc和_Tp可能是您實現的內部符號，也可能是您的實現不符合要求。無論哪種方式，你都應該看看實際的標準，而不僅僅是一個實現。 – smithco

是否有良好的/廣泛採用的C++模板編碼慣例/標準？

回答

相關問題