這個世界上絕大部分編程教材是針對剛入門的程序員寫的，沒錯，很多編程二十年的程序員其實也剛入門。

以前帶隊時我總是提醒新招的C/C++程序員盡最大可能不要使用macro，我會警告他們macro有一千種可能令他們的代碼出錯并且查不出來，之所以有一千種是因為我不想再數下去了。然后他們打開我的代碼以后就抓狂了。

如果你問一個程序員什么樣的代碼bug最多，會有很多回答，比如coding style，復雜度，blablabla…

都對，因為他們都是初級程序員。

但是，對于一個資深高級程序員，一個架構師，一個真正的高手來說，其實真正的殺手是代碼長度。越短bug越少，不管它多復雜，越長bug越多，不管它多簡單。

human error，that simple！

除了極極極少處不得不使用macro的場景，我使用macro都是為了縮短代碼。

可讀性？這個真的非常非常非常重要！是的，對于高手來說，“短”就意味著可讀性不會太糟，邏輯復雜性并不是問題。如果你讀不懂一段“短而tricky的”代碼，說明你不是高手。

當然，你可以質疑哪里有那么多高手？沒錯，但我為什么要讓那些低手看明白我的代碼？讓他們自以為看明白以后去糟蹋嗎？

如果是一個真正的高手接手了我的代碼，并把我狗血淋頭的大罵一頓，沒問題啊，他批評的一切我都認同，我誠懇認錯，反正你已經看懂了。

但我還是會反復警告新手，盡一切可能避免macro！如果聽者是個高手，他本來就不必理會我的blablabla。

以前我?guī)У慕M里有一個高手，代碼能力比我高多了，好多macro的技巧我還是跟他學的，但他極少用，我完全贊成他的理念。

如果說最壞的編程習慣，其實是copy paste，可惜這才是大多數程序員最常見的毛�。ūM管幾乎人人都清楚）。我在這一點上非常極端，一行C/P都不可以，我見過太多太多摔在這里的案例，每一行C/P（或相似體）我都會堅決去掉，能抽象成函數的，做成函數，出于性能考慮的，用inline，去相似性，能用template也行，如果上下文太多沒法函數化，最后一個選擇就是macro。

macro是一匹桀驁不馴的烈（劣）馬，但是對一個好騎手來說，只需要馴服一次。

對宏功能的批評，請參閱C++之父的言論——沒想到吧？

現代編程語言一般都支持編譯期常量，常量可以在大部分情況下代替宏，因此沒有多引入宏這個特性。

C語言和C++為什么要支持宏呢？當年編譯器技術還不夠成熟，所以C語言代碼文件需要分成頭文件和源文件兩大類，在編譯的時候還有額外一個階段叫做預處理階段，宏就是在這個階段被替換成實際的值的。

現代編程語言不再需要區(qū)分頭文件和源文件，也沒有預處理階段，那么為了使用宏而多加一個編譯階段屬于棄本逐末，所以現在的編程語言也就干脆不用宏了。

當然可能有朋友會說，宏這個東西可遠遠不止定義常量這么簡單。我也承認宏也可以展開成非常復雜的東西，但是這時候宏就是一個非常危險復雜的特性了，我認為編程語言搞這種東西實在是沒什么意思。與其關注于宏，不如為語言添加一些語法糖什么的更好。

宏這種東西，在C語言上一經問世、就走向讓人看不懂的宏才牛逼的炫技道路，首先你必須明白：宏不是函數，不占內存，不參與編譯，視圖用宏代替函數的做法本身就是有危險的做法。

在面向對象的編程中，萬一有人視圖用宏編寫一個類成員函數呢？而且要在內存中實例化，……，所以JAVA說：宏你去死吧！

很多語言和很多公司排斥宏并不是技術原因，而且是向現實的妥協！

因為現實的情況是【行業(yè)中有太多沒有技能，沒有責任心的程序員】！

宏是一個好工具，但它不是平庸的程序員能駕馭的。。。但是，唉，我也實在有點感到悲哀，這么多小朋友居然連宏都hold不住該怎么寫程序？！

一個宏套宏，把人可以搞暈。

宏其實就是一種文本替換，純C用它實現類似函數和模板的功能。

C++的模板也有點類似文本替換。

這兩種東西可讀性都不咋的。

不安全。

宏的作用就是替換，或者說助記，一般會給一些常用的方法定義成宏，使用的時候直接用語言寫出來就好了。宏的實現也非常簡單，文本替換而已。

但是缺點很明顯，宏是不安全的，沒有任何的檢查，即使出現問題也不會第一時間知道，定位錯誤也會有困難，特別是引入復雜的宏函數以后。

現在很多高級語言變成了解釋型語言，甚至使用動態(tài)數據類型，那么對于宏來說，失去了類型檢查，其危險性就更高了。

工具就是工具，能不能用好取決于人。

Linux內部就有大量的宏，卻不會有違和感。

并沒有棄用宏，但使用宏定義必須規(guī)范，保證可讀性。換言之，如果程序可讀性差，毛病不在宏上，而是編程的人

有的場合必須用宏，確實很牛。

如果不是必須，就不要用了，用錯了代價太大。