前兩天跟同事做代碼走查，看到代碼里面很多這樣的寫法。
enum {OK, ERROR};
WORD32 calledFunc();
{
if(cond)
{
return ERROR;
}
return OK;
}
void func()
{
if(!calledFunc())
{
//do something
}
}
看到if(!calledFunc())時(shí)，我很疑惑，calledFunc()的返回值類型不是bool，為什么在判斷條件中要用!。他說，他想在函數(shù)calledFunc()返回成功時(shí)做些事情。他繼續(xù)說到，你看，成功時(shí)返回OK，OK == 0，(!OK) == 1。聽起來倒也挺有道理。但是這其實(shí)是一種典型的巧合編程。
首先，為什么要跟我做這么多解釋？解釋類似于注釋，是代碼沒有表達(dá)作者意圖的體現(xiàn)。而事實(shí)上，這段代碼也是存在隱患的。假如有一天，某個(gè)后來人心血來潮，想增加一種錯(cuò)誤類型，枚舉的定義變成這樣enum {FATAL_ERROR, OK, ERROR};，再看看if(!calledFunc())，還是之前的邏輯嗎？但是如果代碼明確地寫成if(OK == calledFunc())，無(wú)論枚舉值如何變化，代碼邏輯永遠(yuǎn)不會(huì)出問題，這就是代碼的可擴(kuò)展性?？此圃谀撤N巧合下兩種實(shí)現(xiàn)的結(jié)果相同，但是不良的編程習(xí)慣產(chǎn)生的代碼是脆弱的。我們不能僅僅局限于代碼的語(yǔ)法，眼光應(yīng)該放的更遠(yuǎn)，應(yīng)該穿透到它背后的價(jià)值觀去認(rèn)識(shí)它，這樣的得到的知識(shí)才是牢靠的，經(jīng)得起考驗(yàn)的。
不幸的是，我并沒有機(jī)會(huì)在代碼走查現(xiàn)場(chǎng)說明我的這些想法。因?yàn)?，我的同事表現(xiàn)出了極大的排斥情緒，他覺得我是在吹毛求疵，他認(rèn)為不應(yīng)該在這種不影響當(dāng)前代碼正確性的問題上斤斤計(jì)較。在我看來，這些細(xì)節(jié)恰恰體現(xiàn)了一個(gè)程序員的習(xí)慣問題，這些看似微不足道的習(xí)慣，每一個(gè)背后都有一個(gè)價(jià)值觀支撐，正是這種日積月累的持續(xù)思考和習(xí)慣養(yǎng)成，體現(xiàn)出一個(gè)優(yōu)秀程序員和一個(gè)普通程序員的本質(zhì)區(qū)別。不斷刻意練習(xí)去夯實(shí)好的習(xí)慣，讓它變的像水和空氣一樣平常，才能生產(chǎn)出行云流水般的軟件作品。連Kent beck 這樣的大師都說自己算不上一個(gè)偉大的程序員，僅僅是一個(gè)擁有良好編程習(xí)慣的程序員，這讓我越發(fā)堅(jiān)信習(xí)慣的力量，并且將在自己的職業(yè)生涯中孜孜追求。
