在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不是他整理的，他自己都不知道每个程序在使用的时候应该注意些什么，于是一用就错。

算法名言(含义深刻啊)