計算機系學生，感覺自己編程能力很差勁，怎麼提高自己編程能力？
我是計算機系大二學生，已經學了兩個學期C++，現在還是覺得自己寫代碼能力很差。只能寫出很簡單的程序，稍微複雜一點就沒有頭腦了。我C++的理論學的還可以，考了80多分，但是到了上機做實驗就沒有思路，別人的代碼自己可以看懂。到了現在在學數據結構，書上的演算法程序基本可以看懂，知道每一行是什麼意思。但是讓自己寫（比如說鏈表，隊列等等這些的基本操作）就寫不出來。。（上網看了一些經驗很多都是說多練，現在我不知道自己該練什麼）請問大家，我現在用什麼方法提高自己上機寫代碼的能力啊。很是謝謝大家回答
給親推薦Changelog Media的主編和合伙人Jerod Santo寫的一篇文。這篇文他分享了如何能提升編程能力的方法，希望對你有所幫助。
以下為文章全文：
正如每個人都知道的那樣，寫更多的代碼是提高編程能力最顯著方法。但是我所確信的另外一種可以提高編程能力的方法是與寫代碼完全相反的。我將要儘可能清楚的陳述這種方法。
只有大量的閱讀別人的代碼才能顯著的提高你自己的編程能力。
不論你是否相信，但是我覺得你可以試一下，你會覺得自己所花的時間是完全值得的。
在這篇文章里我將會教你如何選擇閱讀的內容以及教會你如何閱讀。如果你已經知道如何閱讀代碼，或許你已經發現通過你的努力可以獲取更多。如果你還不知道如何很好的閱讀代碼，那麼請一定繼續往下看。
讀什麼
我們很難決定閱讀什麼樣的代碼，也很難給別人建議。我不會簡單的給你指出你應該讀什麼樣的代碼，因為它最終還是取決於你喜歡讀什麼。我會給你提供一些參考，使得你能夠有所側重的去選擇閱讀什麼代碼。
閱讀你信賴的代碼
你已經在使用的插件或者庫會是很好的選擇。
一個你十分喜歡的WordPress plugin
一個你已經發現很有用處的Ruby gem
一個你會經常回顧的jQuery plugin
這些都是極其不錯的可以作為候選的地方。如果你已經對其公開的APIs十分的熟悉，那麼理解其內在的工作原理已經不再是一件困難的事情。另外，作為一個代碼的使用者，你有機會為其添加文件，實現一個新的功能，或者對原來的項目提出修改的建議。
閱讀那些能夠讓你眼前一亮的代碼
我還記得第一次看 280 Slides 的時候就心想這些代碼讓我眼前一亮。隨後我迅速發現這個網站的源代碼是Cappuccino的開源項目。當這一信息在我的大腦深處徘徊的時候我猛然想起另外一個讓我印象深刻的軟體也是運行在Cappuccino上的，這時候我知道了有一個我可以學習到很多東西的項目了。有什麼是讓你最近印象深刻的？它是一個開源項目嗎？如果是的話，那麼它將會是一個值得你去讀的代碼，因為這些代碼會像最終的應用一樣吸引你。
讀那些你認為是大牛所寫的代碼
如果你已經用開源項目的軟體編程了一段時間，
那麼肯定有發現其他能夠讓你印象深刻的程序員。
我的腦海中有那麼幾個能夠寫出讓我十分羨慕的代碼的程序員。
如果你的印象里還沒有這樣的開發者，只要你願意的話是很容易找到一個的。他/她或許在過去已經寫了屬於以下2個類型中的代碼。（一種是你所依賴的，另一種是令你印象深刻的）
讀那些你可以意會的代碼
如果你勇於冒險的話，那麼有可能會考慮深入研究類似Ruby on Rails, Drupal, 或者 jQuery的大項目。我建議你現在最好不要接觸類似的項目，除非你在閱讀代碼方面已經很有經驗了。
大的項目有很多可以移動的模塊，你可能會糾結於很多概念而無法及時學到很多知識。疑惑會令人泄氣，在閱讀大的項目的過程中更加容易產生疑惑和泄氣的負面情緒。從一個小的項目入手的好處在於整個程序的完整邏輯可以在腦海中浮現。剩下的就是去探索其細節並從中學習。
如何閱讀代碼
既然你已經選擇了一些要讀的代碼，那麼什麼是最好的閱讀方式呢？我在過去閱讀了許多的代碼，因此可以給你推薦一些可以最大化投資回報率的方法。
下面請看這張大圖
假設你已經在閱讀代碼方面達到了一個突出的水平了。如果沒有，那麼建議你去查看項目的網站、使用說明書、文件或是任何除了代碼外幫助你理解的內容。
那麼，我首先建議的是使自己的腦海里有這個項目清晰的框架。其工作量是基於你所選取的代碼庫的大小。但是只要是大於一個文件的項目都會消耗一定的時間。
首先對文件的結構加以注釋。如果一個編者的文件具有像TextMate一樣的可視化視圖結構將會極大的幫助這一步驟的完成。譬如這裡有一個Twitter Ruby gem的完美概要。
這一步驟的目標是為了讓你更加的熟悉代碼。找出那些文件包含/需要/載入其他的文件，以及代碼主題的位置，是否用過命名空間，或是其他諸如此類的東西。如果你已經了解了大的架構，那麼你就可以深入去關注其細節了。
記錄下你所發現的東西
閱讀代碼應該是一個主動的行為。我鼓勵你根據自己的想法增加一些評論，當你理解程序的流程的時候記錄下你的假設以及自己的結論。那麼剛開始的時候你的評論可能是這樣的：
當你的理解不斷的進步的時候你會減少那些碎片化的評論並且能夠增加一些更加有意義或權威的評論，這些評論或許能夠對完善原來的項目有所幫助。
使用測試，Luke
但願你選擇的項目有測試的套件，如果沒有的話你可以完全跳過這一部分（或者重新選擇一個有的項目）。
測試是一個很好的地方能夠讓你隨時閱讀別人的代碼因為它們記錄了這些代碼需要實現的功能。一些測試能夠提供很多的信息，但是不論寫的有多好，你在測試里可以比在執行里更好的發現作者的意圖。在你閱讀代碼的時候盡量讓其測試的套件成功運行。這會讓你的開發環境得到合理的配置，也會讓你更加自信的去做出一些改變。
執行，調整，再執行
誰說看代碼的時候就不能執行代碼？只有將一切東西拆解再將其恢復原樣才能真正的理解其本質。還記得那些你所經歷的測試嗎？在失敗後，增加一些代碼，或者在不破壞的前提下改變其執行的情況。嘗試增加一些你覺得很酷的小屬性，或者在項目範圍內增加一些記錄，這樣你就可以在編寫代碼的不同階段列印輸出。這些還僅僅是閱讀代碼嗎？
這是毫無疑問的，但是從這個角度看更像是一段奇妙的經歷而不是閱讀一篇神秘的小說。這是一件非常好的事情。
沖洗和重複
一旦你閱讀完一個代碼庫，立即選取另外一個並重複之前的步驟。你只有閱讀足夠多的代碼，才能提高閱讀新的代碼的效率。你會發現你的投入產出比在不斷的上升並且發現這是一個十分有趣的學習過程。
從哪裡開始
在我的代碼閱讀資源中，GitHub是對我影響最大的。在這個網站里，你能夠很快找到新項目以及其作者，如果你不使用這個網站那麼對你來說是一個很大的損失。我建議先從GitHub上開始直到你能夠找到一個可以學習的項目。記住下面這段話並開始閱讀吧。
你是怎麼看的？你是把閱讀代碼當成一種學習的手段嗎？你會給別人推薦哪些項目？最近是否閱讀過很好的代碼？
因為The Wayback Machine的緣故你可以閱讀到原來的文章。
作者介紹：Jerod Santo是Changelog Media的主編和合伙人。他聯合主編了旗艦博客—The Changelog，他領導了所有使得Changelog變得更加酷炫的項目。他也經營著自己的訂製軟體公司Object Lateral。
本文原文
更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎
實際做個系統會有幫助。但是對於今後發展來說，強烈建議去OJ上面做題。面試Google Hulu FB 後感覺，項目經歷除非做的東西很牛，不如演算法能力重要。
推薦vijos，好處是題全部是中文的，讀題快，並且網上能搞到測試數據。POJ題目難度梯度大，容易踩到雷。 TopCoder比較國際化，定期有比賽。
成年人的思想還能進步么？ ? 學而時嘻之 ←先看完這篇，然後按照裡面說的要求（*重要*），不斷地編程！
我估計題主學的時候應該是這樣學的：看書，對著敲書上的代碼（或者自己敲代碼），考試80分。如果真是像我說的這樣的話，那編程能力肯定是不夠的。書上的例子只是讓你理解知識點，等你敲到有手感的時候，就沒得寫了。要有一個真正的提高，肯定要去做一些小程序。比如，你可能參加了許多社團，認識了很多人，但是有很多人的名字都記不住。那你能不能寫一個通訊錄的程序出來，能夠存儲聯繫人的信息。1.0版本做出來了，你能不能實現像有道詞典單詞本那樣的定期通知複習，讓你可以記住更多的人？……就這樣一步步加功能上去。
其實類似於這樣的生活中的需求都可以做成一個程序，從而來提高編程能力。最重要的，是你開始去做了。很慚愧的是，我自己雖然想法挺好，但還沒去做呢。。
你說到的能寫出簡單的程序，但是遇到鏈表、隊列等等數據結構實現就搞不定了。其實，我那時候也是這樣。甚至現在大四了，如果不去認真理解再寫幾次，我估計我也寫不了。List/Stck/Queue以及圖、樹、排序都不難理解，但想要實現並且隨時可以寫出來，甚至應用的話，沒有付出一定時間和精力，是做不到的。我給的建議是，先理解程序的實現。理解之後就要立刻開始自己試著去實現它，一開始可以邊看邊敲，跟一下思路。之後再刪掉代碼，繼續敲，這次就別看書了。然後刪掉，繼續敲，運行。刪掉，敲，運行……一直到你能完全不看課本，敲出代碼並且完全沒錯為止。這是一個過程啊，看似重複，有些浪費時間。但是你敲每一次都是在腦海不斷調整對這個數據結構的理解，每一次都在你腦海中構建對這種數據結構的理解。這是我的理解，你可以試一試，我是這樣做的，感覺挺管用的。
其實有一陣子我也覺得要去看國外的好書，但買了好多好書，到現在連一本看完的都沒有。其實，我覺得選書要根據自己現在的層次去選，剛剛入門，英語不好，就立刻去看國外的書不一定比看國內的書好。等你國內的書看得差不多，真的覺得國內的書不能滿足你的需求的時候，你再去看國外的書也來得及。先看翻譯的，再看原文的，循序漸進嘛。個人覺得最忌諱的就是聽別人說國外的書好啊，然後全部就換成國外的，後來發現看都看不下去，最後還是得換回國內的。別人說的不一定適合自己，適合自己才是最好的。
話說現在國內計算機教育的一大問題就是只教看得見的，不教看不見的。
看得見的是語言的語法、程序的流程、各種理論和概念。看不見的是「計算思維」。
考試成績還不錯，說明你讀書背書能力很強，但是並不一定有很好的計算思維。
所謂計算思維，就是「以計算機的方式去對問題進行思考」。這種計算思維的培養只能通過大量的例題來進行。這也就是說想要學到計算思維，首先要對這個領域充滿興趣，不至於因為大量的題目讓自己失去耐心。
培養計算思維有兩個方向。
一個就是「學術范」的ACM/ICPC等等的比賽，這種問題對計算思維的提升非常有幫助。而且這種比賽題目、答案、目的都非常明確，非常適合用來訓練計算思維。
另一個是動手做一個項目，做一個看得見摸得著的項目。我所接觸的學生，他們對計算機的信心和熱情逐漸被屏幕上的黑框消磨殆盡。所以你需要一個極大的興趣點去推動自己。例如你可以去學習圖形界面編程、科學計算編程等等能讓自己提升起興趣的內容。
除此之外，想要提升自己的編碼水平，很重要的一點就是要多看！看別人的代碼。一行一行地為別人的代碼添加註釋，從而了解到這個問題「通常」的解決方法。這能夠為後來親自編碼時提供很多幫助。這也就是「讀書破萬卷、提筆若有神」的道理。
當然，對於日常來說，讀書是用來提升編程水平最重要的手段（甚至我認為是唯一的手段）。什麼看視頻聽講座，充其量是個為了快速入門而投機取巧的方法。
看書也是要有選擇的（請不要認為我崇洋媚外）：國內的大學教材以後基本可以扔掉了。因為隨著專業知識的深入，你會發現這些教材基本上都跟國外的某一本教材有著大面積重疊的篇幅，而且就算抄也沒抄到精髓。國外的教材優點之一是言之有據，所有術語必然是先定義後才會提到的。一般不會找不到太大的紕漏。
就算是找到了一本好書，讀書的方法也是很有技巧的。首先我認為一本好書至少要讀兩遍。第一遍用一天完整連續的時間，通讀全書。達到的目標是能夠在把書合上時，能說出這本書的主題，主要解決的問題等基本的內容。第二遍就是針對書籍的正文進行精讀。不過即便是精讀，也是要有側重的。如果是語言類的書，其實你可以掠過部分冗長的敘述（尤其是國內某些人的書，經常是車軲轆話來回說），直接看示例代碼。先按照自己的理解，猜測這些代碼的執行效果，再看書或者上機執行一遍，再比對自己的猜測。如果是理念類的書籍，不好意思——這類書籍就一字一句地去看吧。
還有一點我要說的：計算思維跟計算機語言無關。當你擁有了計算思維再去面對問題時，就會發現這個問題的「計算機解法」而非「C++解法」或者「Java解法」。也就是說，你面對的是問題的本身，而不再是細節。（這也就是為啥計算機界的大牛對編程語言並不一定在行，寫不出產品級的代碼來，但不證明他們就不夠牛）。
總結一下：想要學好編程，一定要動手，每天保證一定的編碼量和閱讀量。可以通過實際的項目來培養足夠的動手能力。而這一切的先決條件，就是興趣
2013.11.15增補：
這是我在知乎上第一個回答，感謝大家的支持，受寵若驚中。。。
有人問「應該怎樣選擇代碼去看去學習」，這裡我來分享一下我的經驗：
如果你還在編程語言上糾結，或者對於某一種編程語言還是入門階段，那就看書上的代碼就足夠了。可以試著給書上的每一行代碼添加註釋，理解這個代碼「能幹啥」。然後自己嘗試小範圍變更一下這個代碼的需求。按照自己想想的新需求，將書上的代碼改造一下。然後猜想一下自己的代碼能不能實現這個功能、這個功能的最終結果如何。
如果你正在學習某個框架庫的使用，那最好的方法就是去官方文檔上面把示例代碼都運行一遍，再按照上面的方法去學習。
除此之外再推薦一種非常鍛煉人讀代碼的方法，就是學會Debug，也就是調試。現在基本所有的IDE都已經支持調試了吧。你所要做的就是在程序入口處設置斷點，然後讓程序單步執行。每跳到下一步之前，都要猜想一下，這裡的某個變數的值將會是多少？然後再執行一步，看看真正的值和想像的值是否一致。
有人讓我推薦幾本好書，我只能說，書這種東西真的是因人而異的。
有些人覺得那種「名字聽起來很霸氣」的書都是垃圾，有些人覺得經典書籍適合入門。更多的人都是人云亦云，別人覺得好那就真的好。好吧，我只能儘力嘗試讓自己客觀地回答這個問題：
（本處只談論程序領域的內容，非科研領域）
1，語言類入門：
《21天學通C++》這本書名字聽起來很霸氣，其實就是把C++中的東西分成了21章去寫。這本書被國內的「大牛」們批判的淋漓盡致，但它已經再版了無數次，賣出去了幾百萬冊（貌似是）。筆者就是靠這本書學會的C++，筆者的網名也是出自於此書的一個Example。
關於Java：筆者的Java是對著官方文檔學的，學習過程還是相當痛苦的。這裡批判一本書就是人人都說好的《Java 編程思想》(Think in Java)。這本書太尼瑪難了，覆蓋面特別廣，對演算法等非編程決定因素的依賴太多了。看網上都在給入門的同學們推薦這本書，這類人無異於在教linux新手sudo rm -rf /
關於Python：其實這個才是筆者最常用的語言~但是Python的中文書比較少。推薦一本《Python 基礎教程》，圖靈出版書。比較適合入門。
之所以叫做語言類入門，就是因為「僅憑書，只能入門」。想要成為大牛，還是要多寫代碼！代碼量到20w行基本上就算大牛了（當然不包括自動生成的亂七八糟的框架）。
2，思想類：
《設計模式之禪》：這本書算是我覺得國內寫的比較好的書了。其實國內在有了圖靈、Apress、華章等社進駐之後，國人寫的書越來越能看了。（讓我深深鄙視一下清華社，一如既往地爛幾十年可不容易）。
《Restful in Action》：筆者最近在研究這個，覺得這本書還不錯，故推薦。
學計算機卻不寫代碼，就像學搏擊但不實戰，最終只會花拳繡腿。
因為計算機的理論都是基於大量的實踐和反思所總結出來的經驗。所以實踐不夠，是無法理解理論背後的實際意義的。
所以我對題主的建議是：
1.數據結構、演算法，最好都能自己實現一遍
即使是參考著書來寫也沒關係。動手實現不但能讓你真正認識到每一行代碼的意義和各種數據結構、演算法的目的和差別，還會潛移默化地教曉你一些編程的原則。
舉個簡單的例子，鏈表有很多種，單向、雙向、循環。
實現兩三種之後，你會發現其實它們所提供的都是同樣的功能——一種有組織有紀律的數據儲存方式。那麼可不可以利用C++的繼承來做一個介面，而不同鏈表作為具體實現呢？這時候你不但學到了鏈表作為數據結構的意義和實現，還結合了面向對象的理論，讓你的編程能力得到提升。
2. 設計模式、系統架構需結合實際
以後你還會學到設計模式、系統架構等等的知識，這些和數據結構、演算法不同，是更加『虛』的知識，需要結合實際項目，才能真正理解它們的意義。
舉個例子，觀察者模式，以下是維基百科裡的定義：
一個目標物件管理所有相依於它的觀察者物件，並且在它本身的狀態改變時主動發出通知。這通常透過呼叫各觀察者所提供的方法來實現。此種模式通常被用來實作事件處理系統。
坦白說，很晦澀，如果沒見過代碼、沒運用過，我也不知道它有什麼用、解決了什麼問題。
但如果你寫過處理UI事件的代碼，你就會知道觀察者模式解決了事件和處理邏輯『tight coupling』的問題——一個按鈕可以促發『儲存輸入框內文字』，同時又促發『將輸入框清空』，以後有新的需求，又可以方便地加入『聲音反饋』的功能。
然而，設計模式、系統架構，又是十分容易陷入『唯權威論』的誤區——權威說是怎麼實現的就要怎麼實現。其實設計模式、架構的名字只是某一類解決方案的簡稱。只要合情合理，你可以幻化出無數的變形。一個案例就是經典MVC和Web MVC的區別，雖然都叫MVC，但差別還是挺大的。這裡就不展開了，有興趣的話可以看看 MVC和三層架構有何區別和聯繫？ 中的圖示 
3. 軟體工程需要結合實際多人項目
軟體工程可以說是一門管理學。裡面的內容都是行業精英的經驗總結的理論化，涉及需求開發、軟體開發、測試、迭代等等等等，還涉及不同的標準、工具、文檔等等。總之內容之高深讓人眼花繚亂。
其實，如果沒有實際多人項目的經歷，軟體工程的內容更像是一堆看不懂的廢話，什麼需求、什麼測試，有必要那麼繁瑣么？
但只要經歷過合作項目，你就會體會軟體開發是一件多麼混亂的事情。第一次合作做項目時，隊友根本不知道我在幹嘛，也不知道我們要做什麼樣的軟體，一切都『存在我深深的腦海里』。而且，當軟體的複雜程度上升時，混亂程度也是正比例上升的。
但一個十分現實的情況是，即便學校有多人合作項目的作業，學生也是很難真正領悟到軟體工程的意義的，因為在這樣的項目里，學生根本沒有『可持續發展』的動力——反正交了作業就不會再碰這些代碼了，而軟體工程，很大程度上就是為了軟體的『可持續發展』。所以參加一個實習是很有益處的，不是為了學什麼技術，而是去體會軟體開發的艱難之處和解決之道。
當然，限於我的淺薄的經歷，我對軟體工程的理解也還是沒有到位的。例如CMMI的實際意義，我就暫時還無法理解，我覺得很有可能是之前的實習和項目都是在小型團隊里，CMMI這時就顯得過於笨重。
4. 可以嘗試Android，iOS，web開發
這些成熟的平台都有成熟的開發工具和大量的文檔，可以嘗試去學習開發，做一些自己感興趣的小應用同時也可以實際運用到一些編程的概念。
不過要記住的是，這些只是手段，不是目的。不要抱死一個平台，而是應該去明白這個平台。
上面幾點，是我關於編程的小小心得，希望能有所幫助
別被誤導，這些系統，安卓程序，ios等等純軟體開發是軟體工程專業乾的事，不是說你們不能做，如果感興趣做也可以。我給你的建議是好好學習本專業的所有專業課，然後像你感興趣的方向發展，計算機編程並不只是coding的，coding很容易學，這樣的人大有人在，叫碼農。而為什麼不讓你去什麼計算機培訓機構學如何寫代碼而去上大學，我認為很重要的一點是學校想把你培養成工程師（咱先不管過程結果自己收錢等因素，光從善良的本意出發）！！而不是碼農（沒有任何感情因素，我現在也是……）！不同的IT方向有不同的從業需求，你不知道以後為了解決問題，哪一個之前學過的不起眼的知識點幫了你的大忙。編程只是其中的一部分基礎而已，是工程師們表達自己思維的方式之一，如果像大好基礎，多做練習，多學習面相對象思想，別那c++一直寫c代碼。你現在才大二，積澱還不夠，少玩遊戲少聊妹子多看專業書，積澱夠了自然就找到路了！什麼？你問我需要積澱多久？有一個統計數據表明，一個人做一份工作從新手到剛有所成就，需要10w小時的練習，自己看著辦吧～
做點能用的東西
這個行業我覺得相對其他行業簡單多了，大學期間具體如下
1、過六級，過就行分不用太高，以後看文檔方便，幹啥都方便...
2、學高數，高數一定要學好，數學沒學好就搞開發只能搞外包和簡單的J2EE，然後到網上發帖"哎~程序員只能幹到30歲"，然後得到一堆笨蛋點贊，獲取些許的認同感和滿足...
3、數據結構、軟體工程、操作系統、資料庫原理都要好好學，當然大學時了解書本上的我感覺就夠了，工作時再買些更高級的教材上一個台階
4、如果以上都成了....那你就可以沒事兒上網作作筆試面試題、看看演算法導論、搞搞ACM...畢業你就火了
1，寫代碼是一個熟能生巧的活兒，就像賣油翁的故事一樣，首先自己不要害怕它；
2，把書上的題目練習全部敲一遍，一定要自己思考了再去敲；
3，不建議過早的接觸項目，對基礎的掌握差不多了再說；
4，萬萬不可糾結於語言，找一個舒服的用即可；
5，不要只顧著敲代碼，不可能一輩子去敲代碼，要找個方向鑽，說到底，程序只是和計算機說話的工具。
說說我的體驗，首先要嘗試著讓自己像計算機那樣去思考。
我大學不是學計算機這方面的，直到三年級才摸到計算機，而且還是XT，但是在二年級的時候，某次在圖書館不經意翻看了一本BASIC語言的教材，就沒有什麼理解上的障礙，感覺如果我就是一台計算機，我就想這些基本語句一樣去思考。或者如果我來發明BASIC語言，就應該是這樣的，比爾蓋茨當然不同意了。
要讓編程成為樂趣。
我現在實際上用的最多的軟體是AutoCAD，在工作中遇到一些操作，我會想這裡用AutoLISP編程來解決會不會更好，提高工作效率而且下次可以直接load，編程在這裡帶給我很大的樂趣和滿足感。
貼一段我寫的某段AutoLISP，這個是用來讀取CAD中現有的表格，形成csv格式的...我喜歡寫一些變態的長句子，沒辦法，不是科班出身，沒有好習慣，而且LISP本身也很變態。
(defun c:rExtTable ()
;選擇表格.
(princ "
選擇表格: ")
(setq sSelect (ssget (list (cons 0 "LINE")))
iIndex (sslength sSelect)
iTemp 0
lX nil
lY nil
)
;構成X,Y表.
(repeat iIndex
(setq dLine (entget (ssname sSelect iTemp)))
(if (equal (cadr (assoc 10 dLine)) (cadr (assoc 11 dLine)) 0.1)
(setq rX (cadr (assoc 10 dLine))
lX (append lX (list rX))
)
)
(if (equal (caddr (assoc 10 dLine)) (caddr (assoc 11 dLine)) 0.1)
(setq rY (caddr (assoc 10 dLine))
lY (append lY (list rY))
)
)
(setq iTemp (1+ iTemp))
)
;將X,Y表排序.
(setq lX (vl-sort lX "&<)
lY (vl-sort lY "&>)
)
(if (not sFile) (setq sFile ""))
(setq sFile (getfiled "輸出文件" sFile "dat" 1))
(if sFile (setq fFile (open sFile "w")))
;對照排序的X,Y表,形成輸出數據表.
(foreach rY (reverse (cdr (reverse lY)))
(princ "
")
(if sFile (princ "
" fFile))
(foreach rX (reverse (cdr (reverse lX)))
(setq sText (ssget "_W" (list rX rY) (list (cadr (member rX lX)) (cadr (member rY lY)))))
(if sText
(setq cText (cdr (assoc 1 (entget (ssname sText 0)))))
(setq cText "")
)
(princ (strcat (chr 34) cText (chr 34)))
(if sFile (princ cText fFile))
(if (/= rX (last (reverse (cdr (reverse lX))))) (princ ","))
(if sFile (if (/= rX (last (reverse (cdr (reverse lX))))) (princ "," fFile)))
)
)
(if sFile (close fFile))
(princ)
)
趕腳還是寫的少，我和樓主一樣。只能看懂寫不出來
謝邀：只是個人建議
編程行業那麼多你要的是哪一種，java、php、ios、安卓、前端。
- 編程行業首先你一定對程序有興趣。不要看見就頭疼學了也沒什麼用。
- 可以去一些交流群吸收一下一些前輩的經驗。
- 貼吧直播交流帖子多和有經驗的交流。
- 選擇一下比較好的視頻教程，視頻太多容易出問題，建議選擇一套比較專業點的。
- 這還得靠自己的努力，多敲代碼，一邊不行就兩遍、兩遍不行就次等到熟練就行。
本科期間好好學習數據結構，操作系統原理，資料庫系統原理與設計，這就足夠了，要學好這幾門，也要花很大的精力。語言什麼的，一個星期就能入門，而上述的是內功。
但是讓自己寫（比如說鏈表，隊列等等這些的基本操作）就寫不出來
略微說重一點，這不只是編程能力不行，理論能力恐怕也不行啊，這可不是「稍微複雜」的內容啊。
既然這些寫不出來，就從這些開始吧。但是不要上來就抱著鍵盤一行行的寫。想一想滿足什麼性質才叫鏈表，什麼才是隊列。想一想你要用什麼來鏈接數據才會有這樣的性質，下一步想清楚用什麼C++中有的內容可以做出這種鏈接來。最好不要畫太多圖（結構複雜了再畫圖），盡量自己想像。
多思考，多動手。不要ctrl+c，時間久了自然就水平高了。
找個稍微大一點的系統嘗試去實現它的功能。只有實際操作編程才能提高能力，理論知識對一般的程序員沒用（雖然我大一的時候C語言程序設計考了96分），那些是給考證和架構師用的(個人感覺)
大二了也可以進實驗室了，聯繫一個自己喜歡的方向的老師去實驗室做事，跟學長和老師學，通過項目形勢逼迫自己主動寫代碼解決問題，會學到極其多的東西。
自己寫一個項目（例如還原一個（網頁）遊戲）？老人家沒說錯，編程靠的就是不斷碼字……
不論C還是JAVA，GOOGLE找幾個實例練練手. 不會寫還是ctrl + c 和ctrl +v 用多了，動手太少了.
C 語言，可以寫個.c文件，編譯，運行
百度文庫之類的地方找找實例練手. 明白整個流程原理很重要. 不在乎會寫幾個 if else / while 等等
推薦閱讀：
※遊戲編程裡面有哪些經典或者很酷的演算法？
※為什麼很多人喜歡 Python？
※你最痛苦的一次找程序 bug 的經歷是哪次？
※怎麼將 Android 程序做成插件化的形式？
※30 歲才開始學習編程靠譜嗎？