你是否編寫過複雜的
sql查詢語句，但卻不知道最基本的
update
和insert
語句的語法，當使用時還要去重新查詢
msdn
文件來獲取語法幫助；你是否編寫過複雜的程式邏輯，卻沒注意縮排和注釋，只注重高階的東西卻忽視了最基本的，這是好高騖遠的表現。生活中人說字如其人，可以通過乙個人的寫字方式和字的形狀來讀懂乙個人，對映到計算機中同樣有**如其人，可以通過乙個人編碼的方式和編寫的**來讀懂乙個人。
要想成為一名優秀的程式猿細心是不可缺少的素質，但僅僅只有細心是不夠的，另外必備的素質是好習慣。擁有好習慣的程式猿在任何地方都會得心應手，也許在剛開始時會比其他人的速度慢，但他們的加速度和結果要優於其他人。
這是做好乙個優秀程式猿的必修課之一，要知道你編寫的程式不只是給你乙個人看，更重要的是讓其他人一眼就能讀懂。
對於類，在編碼時，說明一定要有，在建立解決方案後也許是程式集**，另外一種可能就是類**，這麼多的類怎麼才能很快的知道哪個是你想要的？這時候注釋就發揮了大作用，通過注釋能夠很快的檢視這個類的功能，知道了類功能就能很快的找到想要的方法。在這裡筆者建議，不妨把每個類的類功能整理到乙個文件中，等到用的時候直接檢視文件比檢視程式集中每個類效率到的多。另外在進行敏捷開發，沒有完整的程式流程圖時，在編碼時不妨把每個功能所需要的類和方法也整理到乙個文件中，這樣在最後開發完成補寫文件的時候就很輕鬆了，這也是走一步看兩步的習慣。
對於屬性和方法，說明更不能少。程式中有類**，另外更多的就是屬性和方法了。好的方法在做到高內聚，低耦合的同時不要忘記對它的說明，當外界呼叫時首先展現給別人的是名稱，其次是屬性和方法的說明，所以好的命名和適當的說明能夠大大提高編碼效率。對於命名規範筆者提倡使用
pasca
l命名法，當然最好不要有縮寫的；對於
.net
在對屬性和方法說明時筆者提倡使用
.net
自帶的，
'''或
///，因為在外界呼叫時能夠很快的看到對屬性和方法的說明。
對於變數和引數，規範和說明不可少。可以說變數是方法的手腳，變數的多少直接決定了乙個方法中編碼行數的多少，也決定了方法的複雜度。良好的命名方法和注釋能夠讓閱讀者很快了解到變數的作用，所以在此筆者提倉採用
camel
命名法，首字母使用型別的縮寫和小寫，後面的單詞是變數的名稱使用首字母大寫。另外還有引數，引數是方法的驅動，有了需要傳參的方法，獲得了引數就有了活力。良好的命名方法和說明必不可少，在此也提倡使用
camel
命名法，如果傳遞的是實體，還要在注釋中說明所需要傳遞實體的屬性，因為在使用實體時有時只使用實體中某乙個屬性就能使方法運作，這使用一定要在注釋中說明所需要的屬性，才能保證下次使用時不會出現「物件未宣告」的錯誤。
做到了好習慣一，不敢保證能夠成為乙個優秀的程式猿，但起碼會受人愛戴，體現乙個程式猿領域的專業化水平。俗話說好記性不如爛筆頭，那麼接下來就是構建自己的**庫，東西是不需要去記憶的，更何況是這麼多**怎麼可能記住這麼多呢，這時候需要做的就是記錄，通過構建自己的**庫來儲存認為優秀的**或者是認為很重要的語法，等到下次不知道怎麼使用的時候直接去查閱即可，可以說它是乙個程式猿的財富。
想要成為乙個優秀的程式猿萬不可固步自封，在這個領域中沒有一成不變的（其它領域中也是如此），深入其中就體會到了學海無涯的滋味。更何況在所有的行業中
it可是發展最迅速的行業，每年都在發生著變革，安卓的出現改變了世界，於是之一批一批人前仆後繼的去搞安卓開發，誰知道下一秒會發生什麼。所以要多閱覽，這裡的閱覽筆者認為大到新聞，小到文章、**，新聞可以增長見識，同時也能為我們指引大方向；而閱讀文章和**的過程就是學習借鑑的過程。一定要學習優秀人員的先進經驗方法，這才是聰明人。
另外千萬不要自私，更不要懶惰。要經常寫作，保持感覺。筆者認為，寫作能幫助我們思考，同時也是整理思路再學習的過程。以前筆者看過一篇關於寫作和程式架構的文章，對寫作和程式架構進行了聯絡，發現通過寫作對文章結構的構思，可以對映到程式架構中。乙個能夠構思出優秀文章結構的作者，經他設計的程式架構也會很漂亮。對於要寫的東西，筆者認為認為可有多種，學習的總結、遇到的問題、開發的程式、所感所悟等等。
歸根一切最主要的好習慣是實踐，多動手，勤動腦，這才是程式猿最好的習慣，當然另外需要有細心、耐心，遇到問題不要膽怯，這樣才能很快的解決它。所以多多實踐吧。
好習慣的養成
1 以後一定要像今天這樣，如果是用別人的 就一定要用注釋寫清楚每一條語句的含義。2 堅持一小下，才能一點兒點兒地發現有機可成 功 才能讓自己地產生 自信，以 樂觀的心態面對生活中的每一件事，開心每一天。3 對自己狠一點兒，一定要多看書，多敲 往往最重要的理論就在細微之處，卻很難被一般人發現。4 我希...
運算元據庫必須養成的好習慣
from 我們開發的系統中，資料是最重要的一部分，如果程式的 錯了，我們可以通過各種方式修改回來，但如果資料失真了，將永遠無法還原，那種欲哭無淚的滋味，相信經歷過的人是深有體會的。可能這些小的細節對我們來說都是微不足道的，但往往這些微不足道而且是小概率的事件將會毀了你。記得剛開始工作的時候，我們專案...
程式設計要養成的好習慣
dry這一法則可能是程式設計屆中最通用的法則了，目前為止，應該沒有哪個程式設計師對這一法則存有異議。但是，我們卻能發現，一些程式在編寫單元測試 unittesting 時忘記了這一法則 讓我們相像一下，當你改變乙個類的若干介面，如果你沒有使用dry，那麼，那些通過呼叫一系例類的介面的unittest...