注：最近低潮一段，加上本人處于高原期——水平急待提高的階段，所以一直郁悶，做題相當少，貼休息時看到的好文章充數……

在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不是他整理的，他自己都不知 道每個程序在使用的時候應該注意些什么，于是一用就錯。