公司來了幾個新手，有時候很簡單的乙個功能模組都要耗費好幾天時間，總是在一些不相關的問題上死耗一整天，搞出莫名其妙的問題，找不到具體原因，總是懷疑編譯出問題了，系統出問題了，板子出問題了，搞到快下班了叫我幫他們看看。
我總跟他們說，不要輕易懷疑系統，先去檢查自己的「所作所為「，雖然系統也會有出錯的時候，但是你永遠要相信你自己出錯的概率遠大於系統，99.9%的時候都是你自己出了問題。
首先，靜態檢查自己所寫的每一行**是有必要的，雖然有時候編譯通過並不代表程式沒有問題，只能說明語法上通過了，但是是否真實按照自己的設計意圖編寫的，卻很難說。
程式設計習慣不好，很容易在匆忙大意的時候改變了程式的設計邏輯，但是編譯卻能正常通過，自己卻還不知不覺。
舉兩個程式設計習慣的例子供參考。
一、運算子與字元之間最好保留空格。
如下對比
int a=2;int b=3;
int c = 4;
int d = 5;
可以明顯看的出來，後面兩行會更加舒適美觀，但這不是我要說的重點，重點時候有時候這可以規避一些問題。
再看下面的**塊
/* no space */int comp_var(int *b)
上面這部分**編譯時無法通過，設計者原本意圖是想計算a 除以 b指標的值，但是/*b 會被編譯器解析成/* 表示注釋開始，b屬於注釋內容，還會一直尋找最後的*/注釋結束符。
加上空格之後就消除了這種歧義。
/* with space */int comp_var(int *b)
else
}
二、變數與常量進行==比較時，最好把常量寫前面，變數寫後面。
這種做法在一不小心將==寫成了=號時，編譯器能及時發現錯誤並告知我們，否則，編譯器直接編譯通過，但是當你執行程式的時候結果總是帶給你「驚喜」。
int comp_var(int a)
程式設計者本意是想比較a 和 3是否相等，但是誤寫成了賦值，編譯器能正常編譯通過看，但是程式執行時 if 條件永真，永遠返回b的值4。
如果將常量寫在前面，則編譯器在編譯時便會報錯提醒，開發者可以隨時糾正。
int comp_var(int a)
好的程式設計習慣 持續更新
1 環狀程式設計 環狀程式設計思維，主要體現在資源的使用上，要形成乙個環狀 自0開始，亦終至0。中間階段則是在使用分配的資源，最終要將資源 不能造成溢位或者資源的多餘。2 極限 在編寫函式的時候，要考慮一些極限個資料的情況。比如排序，要考慮入參為0個資料的情況。諸如此類，要注意總結。3 定製樹 如果...
學習程式設計最快捷最有效的方法
當然，一開始是看書 呵呵，不要扔雞蛋 不看書你怎麼知道 int main void 是什麼意思？不看書你怎麼知道語句後面要加 不過呢我說的看書不是說死啃書，每段都仔細看過來 還記得標題嘛？最便捷最有效 看書是為了了解基本的語法規則，就如我上面所說的 懂了hello,how do you do才能和外...
一些好的程式設計習慣
1.盡量不要用立即數，而用 define定義成常量，以便以後修改。2.使用sizeof 巨集，不直接使用變數所佔位元組數的數值。3.稍微複雜的表示式要積極使用括號，以免優先順序理解上的混亂以及二義性。4.不很容易理解的表示式，要分寫成幾行 5.巢狀的if else要多使用 6.單個函式的程式行數最後...