原文地址:http://www.cppblog.com/littlekid/archive/2008/04/13/coding_skill.html
在ICPC比賽中，個人 能力方面，如果粗略地分的話，大致可以分爲算法能力、代碼能力和查錯 能力。那些大學纔開始參加比賽的選手，寫代碼的基本功一般會比較紮實，主要瓶頸應該是算法能力。而對於OI轉ICPC的選手來說，代碼能力往往是最大的缺 陷。隨着OI轉ICPC的選手逐漸增多，代碼能力的問題愈發暴露了出來。
一、如何定義代碼能力
Comars曾經給代碼能力作過一個比較準確的定義。2004年暑假時，Comars曾經說 過：他認爲150行以內的題目，他的1Y率非常高，並且保持穩定；而當代碼長度超過150行以後，1Y率就開始急速下降了。如果我們畫出一條1Y率的曲線 的話，150行就是一個轉折點。我們不妨認爲，150行就是Comars當時的代碼能力。一年以後，經過努力，Comars把代碼能力提高到了250行。 不過，這已經是後話了。
二、如何提高代碼能力
我一直覺得寫程序和寫文章是一個對很好的類比。
寫文章需要先從宏觀入手，構思文章的結構。寫程序同樣需要。一個好的結構，就是一個好的開始。一個好的開始，是成功的一半。
一篇好的文章需要各種句式和詞藻的合理組合。體現到寫程序上來，就是一些單句以及三五行的小結構的熟練使用。這些都是需要平時總結和積累的。
但凡文章寫得好的人，一定看過很多別人寫的文章。同樣的道理，多看別人的程序，用心地去看，也可以提高自己的代碼能力。
我鼓勵隊員去看別人寫的程序，特別是像Comars這樣的選手寫的程序。從優秀的程序中，我 們可以體會別人良好的程序結構，同時也可以學到很多寫程序的技巧——三五行的小技巧。在和Comars做隊友的兩年時間裏，我通過看Comars的程序， 學會了很多小技巧。逐漸地，我覺得我寫的某些程序已經和Comars有點相像了。
那麼，如果身邊沒有Comars這樣優秀的選手可以借鑑，該怎麼辦呢？其實沒關係。任何一個程序都是可以看的。一個程序，就算寫得再差，總還會有一兩個閃光點，要想辦法把它們找出來。另外，程序裏寫得不好的地方，也要一一找出來。
讀程序，從某種角度來看，就像讀史。好的歷史是用來借鑑的；不好的歷史則應該引以爲戒。讀程序也是一樣，擇其善者而從之，其不善者而改之。
三、謹慎地對待STL和SCL
STL - Standard Template Library。在ICPC的選手中，STL是相當受歡迎的。的確，如果STL用得好，程序可以精簡很多。既提高了編程的速度，也提高了編程的準確性。
SCL - Standard Code Library，就是標準程序庫。對很多選手來說，SCL可是命根子啊 :)
我覺得STL和SCL都不是壞東西，但是需要謹慎地使用。
我向來不主張隊員一進隊就開始用STL（雖然這種現象普遍存在 :(）。我認爲，STL的作用是錦上添花，而不是雪中送炭。比方說，一個heap寫得很熟練的隊員，我覺得他可以偷偷懶，用一下STL。但是，那些不太會 寫heap的隊員，就不應該用STL裏的heap。因爲，他們真正應該做的是掌握寫heap的能力——這纔是最本質的代碼能力。
學會用STL是件很爽的事情。但是須知有所得必有所失。如果過早地接觸STL，會讓你失去很多鍛鍊代碼能力的機會。
至於SCL，我的主張是儘量不用。
不可否認，隊裏確實有一些人SCL用得很好。但是，我至今仍然沒有見過一個SCL用得很好，同時有擁有很強的代碼能力的人。同樣是有所得必有所失，你平時習慣了去抄程序，必然少了很多自己構思程序的機會，從而影響代碼能力的提高。
當然，我也不是完全反對去使用SCL，偶爾用一下也是可以的，例如在比賽中。但是，需要注意 的是，一定要用自己整理的SCL。我見過有人拿着一本別人整理的SCL，雖然內容很齊整，但是我沒見他用對過。因爲這本SCL不是他整理的，他自己都不知 道每個程序在使用的時候應該注意些什麼，於是一用就錯。