例程可以有參數，這不是新聞。您可以根據需要定義任意數量的參數，但是參數太多會使您的例程難以理解和維護。當然，您可以使用結構化變量作為解決方法：將所有這些變量放在單個結構中，然后將其傳遞給例程。實際上，使用結構簡化參數列表是Steve McConnell在Code Complete中描述的技術之一。但正如他所說：謹慎的程序員避免捆綁數據超出邏輯上的必要性。因此，如果您的例程中有太多參數，或者您使用結構來掩蓋大參數列表，則可能是您做錯了什么。也就是說，您不會使耦合松動。我的問題是，何時可以考慮參數列表太大？我認為超過5個參數太多了。你怎么看？
3 回答
叮當貓咪
TA貢獻1776條經驗 獲得超12個贊
如果某些參數是冗余的，則函數只能具有太多參數。如果使用了所有參數，則該函數必須具有正確數量的參數。采取以下常用功能：
HWND CreateWindowEx
(
DWORD dwExStyle,
LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam
);
這是12個參數（如果將x，y，w和h捆綁為矩形，則為9），并且還有從類名派生的參數。您將如何減少呢？您是否想進一步減少數量？
不要讓參數的數量困擾您，只需確保它是合乎邏輯的并有據可查，并讓intellisense *可以為您提供幫助。
眼眸繁星
TA貢獻1873條經驗 獲得超9個贊
非常感謝您的所有回答：
令人驚訝的是，找到像我一樣也認為5個參數是代碼健全性的一個很好的限制的人。
通常，人們傾向于認為3到4之間的限制是很好的經驗法則。這是合理的，因為人們通常很難計算4件以上的事情。
正如米蘭所指出的，平均每個人一次最多可以保留7件事。但是我認為您不能忘記，在設計/維護/研究例程時，您不僅要記住參數，還必須記住更多的事情。
有人認為例程應包含所需的盡可能多的參數。我同意，但僅適用于一些特定情況（對OS API的調用，對優化很重要的例程等）。我建議通過在可能的時候在這些調用之上添加一個抽象層來隱藏這些例程的復雜性。
尼克對此有一些有趣的想法。如果您不想閱讀他的評論，那么我為您總結：簡而言之，這取決于：
我討厭制定如此嚴格的規則，因為答案不僅會根據項目的大小和范圍而變化，而且我認為它甚至會在模塊級別變化。根據您的方法正在執行的操作或類應表示的內容，兩個參數很可能太多，并且是過多耦合的征兆。
這里的道義是不要害怕向同行展示您的代碼，與他們討論并嘗試“識別出內聚力低和耦合緊密的區域”。
最后，我認為無奈與尼克非常吻合，并以這種對編程藝術的詩意見解（見下面的評論）總結了他的諷刺貢獻：
編程不是工程。代碼的組織是一門藝術，因為它取決于人為因素，對于任何硬性規則，人為因素都過于依賴于上下文。
添加回答
舉報
0/150
提交
取消