偶然看到這麼一篇文章,**過來,等有空逐條分析一下,碰巧,bs和lr的書都在……
「c++之父bs說林銳錯了」之原因
前天發了乙個貼子「c++之父bs說林銳錯了」
c++之父的c++聖經《c++程式語言 特別版》中說:
大家不要聽某些人說判斷指標是否為空用(p==null)或(p!=null)的格式,c++之父認為這樣寫是不好的,提倡直接寫(p)或(!p)的形式。
林銳在國內程式設計師界也是大名鼎鼎的人物,有大作《高質量c++/c程式設計指南》,說判斷指標是否為空要用(p==null)或(p!=null)的格式,別用(p)或(!p)的形式。
那麼大家聽誰的呢?
我認為是c++之父bs的正確。
理由暫且不說,讀者可以自己想一下了。
-----------------
現在我說一下我的理由。
1.如果乙個語言要程式設計師用p==null的形式來標誌那是乙個指標,那麼這個語言的設計一定是拙劣的。
2.如果語言並不要求程式設計師用p==null的形式來標誌那是乙個指標,但程式的設計架構卻要求,那麼這個程式的設計架構一定是拙劣的。
3.如果語言與程式總體設計架構都不要求程式設計師用p==null的形式來標誌那是乙個指標,但是程式設計師自己卻非要這麼做才能容易的識別出指標,那麼這個程式設計師的程式設計方式就一定是拙劣的。
4.如果語言、程式總體設計架構與程式設計師自己都不需要用p==null的形式來標誌那是乙個指標,但是還是仍然非要這樣做,那簡直……
型別資訊不應當也沒必要非在這裡出現不可。99%的情況下在變數名本身中已經體現出來了,其餘的是在環境中一目了然。
我用的是這種方式,
1.所有的邏輯0判斷都是用(p)(!p)的方式。比如指標和用於邏輯標誌的整型都是這樣,當然bool型的也是這樣,不過我還幾乎沒用過bool型呢。
2.僅與數字0在數學意義上進行比較時才寫成(i==0)的形式。
比如if(i>0)else if(i==0)else ;
不以資料型別區分比較的寫法,而是以用途意義。說白了還是那句話,怎麼想就怎麼編,hthc(「how thinking how codeing」),直接描述出來自己的思維。
邏輯判斷就用(p)(!p),數字判斷就用(p==0)(p!=0)也可以用(p)(!p),就這麼簡單。
如果都用成了(p)(!p)還有乙個好處,一見到這樣的就知道是在與0比較呢。識別非常快。
用那種null的形式,多輸入乙個字元就給以後維護時增加一點麻煩,多輸入乙個字元的本身也給程式設計多帶來了一點麻煩,如果問這點麻煩怕什麼,可是在高度複雜嚴謹的思維過程中不希望有任何這樣無用冗餘麻煩,任何這樣的麻煩都會干擾思路。
至於null==p的形式,表面上這是可以防止if(p=null),但是現在編譯器完全可以對這樣的提出warning,而且有許多成熟的**工具可以檢測出這些異常**,小時候我還不知道有這樣的工具曾經自己寫了乙個。
要知道流暢思維描述形式往往是p==null,那麼寫成null==p就干擾了這種流暢的思維,雖然僅僅是一點點,但是在高度複雜嚴謹的思維過程中要求的是一點點這樣的干擾都不要有,這樣寫就干擾了**的直接表義性,違反了「怎麼想就怎麼編」,違反了「最小驚訝原則」。
甚至連const我也是盡量避免使用,如果乙個程式需要用const去維護其健壯性,那麼說明這個程式的整體設計有問題,我認為程式設計師不應該依賴這些來給自己的程式查錯,這樣的依賴往往帶來更大的隱患。
總之,寫有自描述能力的**,hthc。
(還有幾點,現在暫時想不起來了,等想起來了補上)
向C 之父Bjarne Stroustrup致敬
非常好的文章 c 的 背 影 c 之父bjarne stroustrup印象 左輕侯 2002.11.4 熱愛c 的朋友請不要誤會,我並不是在暗示 c 已經日薄西山 或者任何類似的意思。從語義上來說,c 作為一門程式語言,當然不會有什麼背影。事實上,我想說的是乙個人的背影。因此這個題目顯得有點突兀,...
C 之父的一些建議
1.幾乎不需要用巨集,用const和enum定義明顯的常量,用inline避免函式呼叫的額外開銷,用模板去刻畫一族函式或型別,用namespace去避免命名衝突。2.不要在你需要變數前去宣告,以保證你能立即對它進行初始化。3.不要用malloc,new運算會做的更好。4.避免使用void 指標運算 ...
C 之父給C程式設計師的建議
1,c 裡幾乎不需要用到巨集,用const火enum定義明顯的常量。用inline避免函式的額外開銷,用template去刻畫一族函式或者型別,用namespace去避免名字衝突。類也可以。2,不要在你需要之前申明它,什麼時候用什麼時候申明 當年從c 轉c的時候吃了老苦了 3,不要用malloc n...