2011-10-25 123 views
16

你會怎麼考慮一個更好的編碼風格:在頭文件中聲明函數/方法的參數名稱,或者只在源文件中聲明函數/方法的參數名稱,因爲它可以同時執行這兩個操作?如果您實際上只考慮在源文件中聲明函數/方法的參數名稱,那麼您將如何聲明默認值?函數聲明應該包含參數名稱嗎?

外標題:

//One.hpp 
#ifndef ONE_HPP 
#define ONE_HPP 
namespace eins { 

/** \brief description 
* 
* \param one represents .... 
* \param two represents .... 
*/ 
void function(int,int); 

} 
#endif 

// One.cpp 
#include "One.hpp" 

eins::function(int one,int two) { 
    //Do stuff// 
} 

內部頭:

//One.hpp 
#ifndef ONE_HPP 
#define ONE_HPP 
namespace eins { 

/** \brief description 
* 
* \param one represents .... 
* \param two represents .... 
*/ 
void function(int one,int two); 

} 
#endif 

// One.cpp 
#include "One.hpp" 

eins::function(int one,int two) { 
    //Do stuff// 
} 

我個人的觀點是,第一種方式比較好,因爲用戶實際上是被迫讀的意見/ API和不能誤導讀取參數名稱。但我不確定這一點,實際聲明默認值會破壞我的風格,因爲您必須在函數/方法的頭聲明中這樣做。

+4

你錯誤地認爲你需要包含一個參數名來聲明一個參數的默認值。這非常好:'void function(int,int = 0)'。這是一個默認值的未命名參數。 –

+1

爲了對付您關於消費者的評論被參數的正式名稱誤導,我認爲這是參數名稱不佳的指標。對於在代碼中無法輕易描述的內容,例如特定代碼段的「爲什麼」,文檔是最好的*。 –

回答

23

儘管兩者都是好的並且用得相當多,但在頭文件的聲明中使用參數名稱有明顯的優勢。

大多數文檔系統(比如doxygen)會解析你的頭文件並生成文檔。 作爲一個例子,請看這裏:http://libface.sourceforge.net/doc/html/classlibface_1_1_face.html

看看構造函數的文檔。

比較這

Parameters: 
    x1 X coordinate of the top left corner of the face. 
    y1 Y coordinate of the top left corner of the face. 
    x2 X coordinate of the bottom right corner of the face. 
    y2 Y coordinate of the bottom right corner of the face. 
    id ID of the face. -1 not not known. 
    face A pointer to the IplImage with the image data. 

Parameters: 
    param1 X coordinate of the top left corner of the face. 
    param2 Y coordinate of the top left corner of the face. 
    param3 X coordinate of the bottom right corner of the face. 
    param4 Y coordinate of the bottom right corner of the face. 
    param5 ID of the face. -1 not not known. 
    param6 A pointer to the IplImage with the image data. 

你明白了吧。 :)

+0

+1,它甚至使自動文檔引擎更加冗長。 –

+0

當參數被聲明時,第一個列表是否總是按順序排列?因爲當你實際使用一個函數/方法時,你不知道參數的名稱,而是頭中的位置。 – Sim

+0

@Sim在doxygen,是的。 –

3

我的經驗法則是命名一切。並非每個頭文件在每個函數之前都有很好的註釋,因此參數名稱只有在缺乏體面的文檔時才能解釋該函數。

在最壞的情況下,代表程序員進行一些額外的輸入。它顯示了意圖,除了已提供的任何意見。我從來沒有人主張純粹爲了節省打字而存在的練習。在自動完成iDE的這些日子裏,從未如此簡單。

10

在聲明中包含參數名稱。

最好儘可能以緊湊的格式爲其他開發者提供儘可能多的信息。強迫他們查看評論以確定簡單的參數,這些參數很可能會使他們脫離流程,使他們的生產效率降低,並使他們失望。

3

你應該盡力爲你的函數命名,以便它們不需要包含參數名稱,以明確它們的功能。如果您看到方法原型:

void save(const std::string&); 

它在幹什麼?它保存了那個字符串嗎?或者它保存到由字符串表示的文件路徑?要麼...?

所以,你可以這樣做:

void save(const std::string& filepath); 

澄清。但是這隻有在有人正在看標題時纔會澄清。如果你這樣做:

void saveToFilepath(const std::string&); 

它應該是很清楚的地方。當然,隨着添加更多參數,這變得更加麻煩(但是更多的原因是不要添加太多參數;請參閱Bob Martin的Clean代碼;他讚揚無限和單值函數,對二元函數猶豫不決,對三項功能漠不關心,除此之外不願意)。

所以我的建議是努力沒有理由在你的函數頭文件中包含你的參數名稱,而不是本身的目標(雖然我全部都是爲了減少重複和增加簡潔性)但是作爲啓發式爲你如何命名你的功能。 (請注意,如果您使用的是舊版代碼,則可能需要削減自己的餘額—,但考慮到最終目標。)

此方法意味着您必須停下來思考每次鍵入函數頭部來檢查自己,而不是遵循關於是否包含參數名稱的黑白規則。程序員傾向於提前收費,而不是停下來思考命名等事情,但停下來反思在很多不同層面上都是有價值的。

總之,力求不要需要將參數名稱包含在頭文件中;當你不需要它們時,爲了簡潔和減少重複,不要費心去包括它們。

相關問題