關於這個問題呢，我也不是很清楚，但是之前在其他地方看到過關於這個問題的一些建議，在這裡呢，分享給大家。

1. 不要只為了解決問題而隨意把程式碼都寫在Main（）函數里。2. 一個函式應該只解決一個功能或問題3. 單個函式的程式碼行數最好不要超過20行。4. 要給每一個函式起一個好名稱，做到見名知義的程度方便對程式整體的快速理解。5. 要給函式作注意語句，寫程式碼不只是給自己看的，一個好的程式碼也應該讓別人能容易理解。6. 在編寫一個專案或程式時應事先考慮到需要定義的函式，把且有相同功能的部分抽象到一個函式時，減少程式碼冗餘。

最後呢，我想你需要靜下來慢慢思考，自己到底要寫什麼，不要著急，不要慌亂，一步一步的來。

作為一名老牌碼農，最忌諱思路的打斷，當程式設計師沉浸在自己的世界中時，整個思維是連續性，邏輯性的；一旦有人或者是事，打斷了，那種感覺就像是整個世界變成黑暗一般。

根據我的經驗，先在演算法上搞清楚。不要急著用計算機語言思考問題，要用自然語言反覆斟酌問題的實質和可能的情況。然後，在想辦法實現就可以了。

要把使用的語言有哪些功能最好通曉一遍。這樣有利於自然語言思考演算法，更有利於演算法用最優的程式設計方式實現。比如，一個不知道引用正則表示式的人，就很難用正則表示式的思路考慮演算法，程式設計也不會向這個方向發展。

程式設計之前，並不需要解決全部的問題，隨著程式設計的深入，相關問題的理解會隨之加深，很多好的思路和程式設計方法，會不斷呈現出來。甚至會使您不斷調整演算法。

切記，演算法也不是死的，調整到好的演算法，比用一般的演算法得出想要的結果，更具有挑戰性和創新性，也更能激發程式設計的激情和提高程式設計能力。

還有很多，已經深夜了，有機會再談體會。

程式碼只是程式設計思想的一種具體展示形式，程式設計師寫程式碼有幾個禁忌，不能寫沒有中心思想的程式碼，很多程式設計師寫程式碼都是憑著感覺走，寫到哪算哪，特別是初學者寫程式碼的時候，不講究策略覺得一邊想著一邊寫著是一件特別有意思的事情，任何都需要有程式設計的指導思想指引，不能跟著感覺走，程式設計是一種理性行為不是肆意揮灑，優秀的程式程式碼一定是經過精心設計的，程式程式碼的除錯不是推倒重來，而是在有中心的基礎上進行修復。

寫程式碼的時間段內儘量不要被打擾，因為程式碼一旦被打斷就要重新恢復現場，恢復現場的斷點需要花費一段時間，導致很多程式設計師在寫程式碼的時候戴著大耳機，就是防止被外界干擾，戴著耳機也不是為了聽音樂消遣放鬆大腦，很多程式設計師喜歡深夜寫程式碼也是這個道理，夜深人靜沒有人打擾，能夠產出高質量的程式碼，程式碼的質量直接決定了模組的穩定性和效能，寫程式碼最忌諱被人無端的打擾，有時候靈感突然之間什麼都沒了。

寫程式碼最直接表現就是把程式設計的中心思想用簡便的方式表現出來，所以要想表達的徹底程式碼質量必須要高。

評價程式設計師水平高低從來都是靠產品說話，程式碼只是內在表現，但也最能從表現上看出程式設計的基本功。

程式碼編寫看纏山,一重纏是一重關；需求如有八重險,不出陰陽八卦形。

下面我談談個人的一些經驗，寫程式碼過程中會有哪些“忌諱”，希望大家參考。

“這個很著急，下週就要上線”

相信很多程式設計師都會遇到這樣的情景，時間緊是程式設計師最大的忌諱。

需求要求很著急，排期並沒有參考程式設計師的意見就定了一個幾乎不可能完成的時間；加班還是可以接收的，但最可怕的是在這麼短的工期內完成編碼工作，那麼程式碼的質量可想而知。

需求不明確

開發說白了是把需求變成程式碼，如果需求不明確就想當然地去開發，很容易和需求南轅北轍；需求不明確的時候，一定要和專案經理或產品經理溝通並明確需求；

而最為可怕的是，程式碼開發差不多的時候，需求變了。

拿到需求立刻動手

這個還是需求理解的問題，程式碼開發之前最好能想清楚流程，也就是概要設計和詳細設計，可以不寫設計文件，但是有必要有著整體的把控。

隨意修改之前的程式碼

在開發過程中，我們經常會需要修改之前的老程式碼，如果沒有搞清楚它們的用途就直接去修改的話，是一件很危險的事情。

所有的邏輯都寫在一個方法裡

有些單位沒有程式碼開發規範，也就造成程式設計師怎麼方便怎麼來；會有程式設計師喜歡把所有的實現都寫在一個類的一個方法裡面，這樣一方面會造成程式碼的可讀性查，另外一方面也不利於程式碼的複用。

下個版本再完善卻沒有下文

有時候開發完一個需求，也想到了有更完善的方案，但是因為開發時間不允許，就打算下個版本再完善，但從此沒有了下文；建議在需要完善的地方，增加//TODO的註釋，很多IDE都是有功能展示這些TODO內容的。

我覺得寫程式碼前要做好準備工作，不然寫程式碼中要反覆修改，會浪費人力時間。寫程式碼前先分析需求，做好設計文件、介面設計，這樣寫程式碼效率高、時間少。