C++博客 :: 首页 :: 新随笔 ::  ::  :: 管理
 

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


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理