記錄一篇今天工作的思考。為什麼不建議函式的有太多引數？
今天做組內**評審時，發現同事的**有乙個小問題，乙個函式新增了乙個引數後有了7個引數，而公司的編碼規範要求，函式的引數不許超過6個。
後來我就研究了一下，為啥不建議函式有太多引數呢？當然函式引數太多，不利於維護，學習成本比較高。除此之外，函式引數太多對效能也有一定的影響。
我做了乙個實驗，觀察對含有6個、7個、8個引數的函式進行呼叫時，到底有哪些不同，測試**如下：
#include void func6(int p1, int p2, int p3, int p4, int p5,
int p6)
void func7(int p1, int p2, int p3, int p4, int p5,
int p6, int p7)
void func8(int p1, int p2, int p3, int p4, int p5,
int p6, int p7, int p8)
int main()
我們看一下func6的呼叫，全部通過暫存器傳遞。
0x00005555555551ce <+8>: mov r9d,0x6
0x00005555555551d4 <+14>: mov r8d,0x5
0x00005555555551da <+20>: mov ecx,0x4
0x00005555555551df <+25>: mov edx,0x3
0x00005555555551e4 <+30>: mov esi,0x2
0x00005555555551e9 <+35>: mov edi,0x1
0x00005555555551ee <+40>: call 0x555555555169
0x00005555555551f3 <+45>: push 0x7
0x00005555555551f5 <+47>: mov r9d,0x6
0x00005555555551fb <+53>: mov r8d,0x5
0x0000555555555201 <+59>: mov ecx,0x4
0x0000555555555206 <+64>: mov edx,0x3
0x000055555555520b <+69>: mov esi,0x2
0x0000555555555210 <+74>: mov edi,0x1
0x0000555555555215 <+79>: call 0x555555555188
0x000055555555521e <+88>: push 0x8
0x0000555555555220 <+90>: push 0x7
0x0000555555555222 <+92>: mov r9d,0x6
0x0000555555555228 <+98>: mov r8d,0x5
0x000055555555522e <+104>: mov ecx,0x4
0x0000555555555233 <+109>: mov edx,0x3
0x0000555555555238 <+114>: mov esi,0x2
0x000055555555523d <+119>: mov edi,0x1
0x0000555555555242 <+124>: call 0x5555555551a7
學習c++還是要學習一些彙編的，可以解決很多問題啊。
最後，東北碼農，全網同名，求關注、點讚、**，謝謝~
為什麼不建議用Table布局
tables的缺點 3 table裡顯示時需要你把單個 有邏輯性的切成多個圖。增加設計的複雜度，增加頁面載入時間，增加http會話數。4 在某些瀏覽器中table裡的文字的拷貝會出現問題。這會讓使用者不悅。5 table會影響其內部的某些布局屬性的生效 比如裡的元素的height 100 這會限制你...
scala中為什麼不建議用return
在scala中使用return的話，編譯的時候會提示the latest statement is method is automatically returned,use of th return keyword is redundant.這個警告是說最後乙個語句的結果會自動返回，不需要使用ret...
為什麼不建議使用儲存過程了
在公司的系統公升級換代中，明確規定在資料庫開發中不允許再使用儲存過程了，以前的老一代系統中，很多複雜的業務邏輯都是儲存過程寫的，那為什麼風光無限的儲存過程不再被寵幸了呢？首先了解下什麼是儲存過程，它有什麼好處，又有哪些劣勢，為什麼現在都不建議使用儲存過程呢？儲存過程 stored procedure...