|
老生常谈的学问。。。
<K's 50 PV> (上）
条款1. 把C++当成一门新的语言学习（和C没啥关系！真的。）；
这一条源于我在《程序员》杂志2001年第4期上看到的《将标准C++视为一个新语言》一文，作者是C++的设计者Bjarne Strou- strup。这篇文章还可以在Bjarne Stroustrup的个人网页上找到。这篇及时到来的文章很好的调整了我的思维，让我有幸在初学C++时就得以拨乱反正的重新审视了C++这门语言和自己对C++的学习，同时也使我就此开始<K's 50 PV>的撰写。其实要对本条款给出一个理由很简单，我只引用Bjarne Stroustrup在此文中的一句话就可以了：“把标准C++拿来当作一个美化后的C或美化后的C with classes来耍弄，只是浪费了标准C++所提供的美好机会。”
[kingofark的收获]：经常拜读大师们的articles，追随大师们的先进思路，千万别让自己活在与大师们不同的时间里。
[参考]：<K's 50 PV>条款28，29。
条款2. 看《Thinking In C++》，不要看《C++编程思想》；
[解说]：于此，我不再多说——因为争议太多罢。这里我向大家推荐我在《kingofark的“五评计划”》系列文章里面关于此书的一些讨论。（在撰写本文时，《kingofark的“五评计划”》已经在撰写中，相信很快能与大家见面。）
[kingofark的收获]：明白了“阴沟里也能翻船”的道理。
[参考]：<K's 50 PV>条款19，21，22。
条款3. 看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自 己是初学者所以就不看；
[解说]：关于这两本书，大家也可以参考我的拙作《kingofark的“五评计划”》系列文章里面关于C++书籍的一些讨论。（在撰写本文时，《kingofark的“五评计划”》已经在撰写中，相信很快能与大家见面。）不错，这两本书的确不太容易下咽，但是大家应该（也早就应该已经）认识到：钻研精神是一个程序员必备的素质。这也是为什么我在好几个条款里说明同一个问题的原因。
[kingofark的收获]：“书山有路勤为径，学海无涯苦作舟”
[参考]：<K's 50 PV>条款19，21，22，30 <K's 35 MPV>条款26。
条款4. 不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；
[解说]：
VC: Microsoft Visual C++
BCB: Borland C++ Builder
BC: Borland C++
MC: Microsoft C++
TC: Turbo C（有时也指Turbo C++）
WC: Watcom C++
各种简化了的、混杂了的口头称谓容易使初学者感到迷惑，这很正常。不过，其实只要稍加留意，这些迷惑完全可以被消除。大家可以注意以下几点：
（1） 由于C++语言（其它语言也是一样）几乎总是要以某个集成开发环境为载体、平台，才能被真正的“使用”，因此人们在口头上容易用一个集成开发环境的名字来意指一门语言（比如VC，BC，TC等）；
（2） 程序设计语言需要一种载体来被运用，这就好像汉语、英语一定要被人用嘴说出来、用笔写出来才能发挥作用一样；
（3） 编译器（或解释器）有时也被集成开发环境的名称所指代（比如“你用VC编译过吗？”实际上应该是“你用VC的C++编译 器编译过吗？”）；
（4） 只要多了解各种词汇的详细信息（一般是其英文全称），就可以很容易的发现一些你本来就该弄清楚的事情；
（5） 在口头上，也请你在不影响正常表达的情况下，尽量说得准确些，不要迷惑更多更新的初学者。
[kingofark的收获]：“我再也不学VC这门语言了。”
[参考]：<K's 50 PV>条款6，9，39，41。
条款5. 不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；
[解说]：这是kingofark我的亲身体会。
我早年学过BASIC，后来学C的时候，手里攥着一本教材，对其中的习题很不屑。有这样一道题：“编写一个程序，在屏幕上打印
*
* * *
* * * * *
* * * * * * *
要求使用本章学过的循环语句。” 其实我当时的眼光在扫到那个弱智的三角形图案时就跳到下一道题去了，全没k">www.codeproject.com。我觉得我们求的这个“次”也并非不够我们学的。这里我再次感谢孟岩先生（myan）以及其他帮助过我的人！
条款19. 在任何时刻都不要认为自己手中的书已经足够了；
[解说]：（1） 计算机技术正以飞快的速度发展和翻新。新技术取代旧技术时发出的兴奋呻吟声此起彼伏，被我们听到。哦，其实那并非呻吟声，而只是有人在用另一种语言说“活到老，学到老”这句话的声音。
（2） C到标准C，C++到标准C++。很多固有的东西也在长肉补血，发展进化。我们要认识到这种改变，跟随发展的脚步。毕竟“发展才是硬道理”。有很多东西把这一切的一切跟你紧密的联系起来。其中之一是书籍。
[kingofark的收获]：把“噢，我的上帝！”改为“噎，我的书！”
条款20. 请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；
[解说]：这里强调的，还是要紧跟C++发展方向，把C++学准，学精。关于《The Standard C++ Bible》（中文版：标准C++宝典）的讨论，我放在我的系列拙文《kingofark的“五评计划”》中进行。
[kingofark的收获]：标准就是标准，不服不行，不学不行，不用不行，不改进不发展不行。
条款21. 看得懂的书，请仔细看；看不懂的书，请硬着头皮看；
[解说]：小孩子刚生下来，是不会说哪门语言的，当然更是听不懂的，只能“硬着头皮”听爷爷奶奶爸爸妈妈哥哥姐姐叔叔阿姨伯伯婶婶说话，听得久了，就会了。学习本身就是一个从不会到会，从不熟悉到熟悉，从不懂到懂的过程。看不懂就不看，等于什么都不看。除此之外，这一点也没什么理由好说的了。如果非要说的话，一来连鲁迅先生笔下的阿Q都懂得“凡事总须研究才能明白” 的道理；二来嘛，总是看些自己轻车熟路的东西，你不觉的太没有挑战性了吗？
[kingofark的收获]：其实阿Q也不是没有优点的啦！
[参考]：<K's 50 PV>条款3 <K's 35 MPV>条款26。
条款22. 别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；
[解说]：说实话，写到这个条款的时候，我都不想再写下去了——因为道理太简单，大凡正常的、读过书的人都知晓。连一些情节简单的电视连续剧都有人要一本正经的看了又看仔细回味（kingofark就不止一遍的看日本连续剧《GTO》和《続?星の金貨》），作为智慧集合的书就更是如此。
[kingofark的收获]：爱吃回锅肉的人也许更容易体会这个道理。
[参考]：<K's 50 PV>的后记。
条款23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；
[解说]：这里建议大家看看侯捷先生的一篇文章《拳拳到肉 掷地铿锵的三本 OOP 绝佳小书》。文章可以在侯捷先生的网站上面找到。大家在这里就先窥其一角吧：
“拿破仑虽然是个矮个子，一生叱吒却俨然历史的巨人。今天我要介绍的三本书，虽然轻薄短小有如拿破仑的身材，在 C++ /OOP 领域里，其份量与影响却也有着拿破仑般的辉煌灿烂。说它们轻薄短小，是的，让数字说话：三本书合起来才256+318+208=782 页，只比 C++ 语言知名教本 C++ Primer 3/e一半篇幅再多一些而已，比起 C++ 语言权威着作 The C++ Programming Language 3/e 也才达到三分之二的页数份量。逛书店时一个不留神，只怕你便遗漏了这些小书的存在。但如果你真遗漏了它们的存在，实在是你的莫大损失。就我个人的编程经验，以及我的教学经验（对象为业界工程师或 大学生），只要是 C++/OOP 设计思维与语言运用本身的问题，非关 problem domain，百分之九十以上皆可在这三本书籍中找到直接或间接的答案。” “以上三本小书的功用不仅在提纲契领地点出重点，也在於对每个主题有深刻的讨论。在这些书籍中，你会发现一些忠告，告诉你应该做些什麽，为什麽如此；也告诉你不应该做些什麽，又为什麽如此。基本而言当然 whys 比 whats 更重要，这便是这些书籍最有价值的地方。至於从速食的角度来看，检阅一系列准则，也比强记一或二本庞杂的教科书更轻松方便得多。”
[kingofark的收获]：领会了这三本书的内涵，你一开始就可以用比圣斗士星矢更高的嗓门儿厉声嘶道：
“爆发吧，我的小宇宙！！！！！！” ——而且百分之百可以爆发——大可不必像星矢那样每次先被打个稀烂才后发制人。
[参考]：侯捷先生的书评。
条款24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；
[解说]：有些不爱钻研的初学者（比如kingofark）甚至连一个集成开发环境十分之一的功能都没有用到。这是一种非常不好的学习状况，应该改变。其实再复杂的集成开发环境也不过就是个工具软件。连软件本身都用不好，那还怎么去做软件？拜托！高级语言还没有发展到可以完全摆脱命令行操作的阶段。在真正的底层，命令行还是不可或缺的。如果你不这么认为，那就说明你的思想够先进——如果你是站在未来人的角度思考的，我承认我争不过你（因为你不可理喻）。
[kingofark的收获]：只摸一下饭碗，是填不饱肚子的；只与情人接吻，情人也是生不了孩子的；光会撒尿不会拉屎，人也是不畅通的。这些道理你都懂，怎么一学编程都晕了？
条款25. 和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；
[解说]：特别把这句话从“浮躁”的种种表现里挑出来，是因为想向大家强烈推荐侯捷先生的文章《漫谈程序员与编程》。该文刊登在《程序员》杂志2001年第5，6期上；在侯捷先生的网站上也能找到。文中专门以小标题“口舌之战有何益”讨论了这方面的问题，希望大家好好消化。
[kingofark的收获]：好羡慕哑巴。
[参考]：<K's 50 PV>条款10-15,49 <K's 35 MPV>条款23。
条款26. 请看《程序设计实践》，并严格的按照其要求去做；
[解说]：机械工业出版社的《程序设计实践》，愿书名为《The Practice of Programming》，由B.Kernighan和Rob Pike这一对技术书籍黄金搭档合著。该书轻薄短小，却包含了两位著者浸淫程序设计领域多年经验的积累和总结，从极具现实性和艺术性的角度讲述了程序设计时需要注意的多方面问题，强调程序设计并不仅仅是编码的观点。精心选择的素材、体贴的叙述方式（还包括上佳的翻译），都使你能够在不经意的字里行间得到丰厚的收获——真的，基本上是天上掉馅饼，你唯一的付出就是张嘴吐出一句“哦，原来是这样的啊！”看看两位著者是如何在本书的前言中说到大家心坎儿上的吧： “你是否曾：浪费了许多时间去对一个错误算法做编码？ 使用了一个过于复杂的数据结构？ 测试一个程序而忽略了其中最简单的问题？ 花了一整天功夫查找一个错误，实际上却应该是在5分钟里就找到它？ 需要让一个程序运行速度快3倍而且使用更少的存储？ 费劲的把一个工作站上的程序移到PC上，或者相反？ 试图对其他人写的某个程序作最简单的修改？ 重写一个程序，原因是你根本无法理解它？这些事都很有趣吗？” 请大家好好体会两位程序设计领域的中流砥柱在风格、算法与数据结构、设计与实现、界面、排错、测试、性能、可移植性和记法这些方面的谆谆教导。
[kingofark的收获]：读完这本书后，才发现自己以前曾是个傻子；这本书连傻子都能看懂；这本书能使傻子恢复成优秀的程序员。
条款27. 不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；
[解说]：C++里面的很多“C的东西”其实都已经不完全是所谓“C的东西”了。C++中的const、struct等等的含义与C中的相比，小有不同矣！关于这一点，还是希望大家多看看书。复用（reuse）我在条款20里的一句话说就是“把C++学准，学精。”
[kingofark的收获]：求精求准，把握分寸，这是大凡天下事的道理，根本用不着kingofark在这里放气。
<K's 50 PV> (下）
条款28. C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密严正声明：对本条款的解说方式决不是kingofark偷懒的表现。详情见本文的后记。
[解说]：请参考条款1。（完）（吐舌头）
条款29. 请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；
[解说]：同条款28的解说。（又吐舌头）
条款30. 读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；
[解说]：关于《Inside The C++ Object Model》：
“C++成山似海的书籍堆中，这一本不是婴幼儿奶粉，也不是较大婴儿奶粉，它是成人专用的低脂高钙特殊奶粉。” 任何技术，习其表皮，即可把玩；探其隐匿，则能熟悉；得其精髓，方可掌故之，如使双手般精良到位。人们对“会”这个字有着不同层次的理解。我以为，通常我们应该以最狭义的方式去理解它。这不是在苛求自己，而是在检查自己是不是足够浮躁。
[kingofark的收获]：沉着的对自己说：“我什么都不会！”。
条款31. 学习编程的秘诀是：编程，编程，再编程；
[解说]：“实践是检验真理的唯一标准”。这句话连中学课本中都有。
其实，“实践”不仅具有检验真理的功能，它还碰巧是个精干的多面手，可以帮助大家做很多事情——只要你诚心聘请它就可以了，甚至连免费咨询电话都不用打——心诚则灵。不说了——大道理，说起来太张扬，恐有人给我带一顶“教条主义”的帽子。
[kingofark的收获]：有些道理很大（甚至比太阳还大），但是真正懂它的人的数目却很小。
条款32. 请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software Construction）》
《面向对象软件构造(Object-Oriented Software Construction)》《设计模式（Design Patterns）》
《The Art of Computer Programming》；
[解说]：对书籍的讨论，我留在我的系列拙文《kingofark的“五评计划”》中慢慢进行。这里只想指出一点：《C++ Effective Object-Oriented Software Construction》一书在国外已经有了第二版了。
条款33. 记住：面向对象技术不只是C++专有的；
[解说]：同条款17。
条款34. 请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；
[解说]：自己输入源代码，且不说可以练指法，它还是一种研读代码的过程，这道理与看不懂原文就翻译不好文章一样。自己一字一句读过，才有可能通过键盘输入，于是自己在不知不觉中就已经读过一遍代码了。我们常说代码总须多读才能明白些，难道你就愿意通过使用源代码光盘的卑鄙手段来放弃自己多一次的仔细阅读机会吗？有人说用源代码光盘也能读代码。然而应该思考这样一点：只看光盘上的源代码，并不能保证你不一目十行、草草了事；而对着书输入源代码，你就不可能一目十行，因为那样的话你根本无法从键盘输入。想想这两者之间种种潜在的差距吧！我想我们还是踏实一点为好。
[kingofark的收获]：光盘上存储的仅仅只是供参考的源代码，不是研读带来的收获。
条款35. 把在书中看到的有意义的例子扩充；
[解说]：同条款5。
条款36. 请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；
[解说]：这一条基本上是在对我自己敲警钟。
早年学习C++的时候，国外的C++书籍还没有引进。至于当时国内的C++教材，要是参差不齐我倒可以满足了（因为毕竟“参差不齐” 意味着并非没有好的），可偏偏就是一律整齐。那些教材的作（抄？）者，大凡把C教材的制作班底拿来remake一下，然后又贴上一些诸如inline、 class、exception这样一些时髦的标签，再大喊一声“cut!”，即宣布一切搞定了，连take 2都用不着 [注：哦，这都是做影评（经常说“这个续集只不过是正集的一个remake”之类的话）、拍电影（导演喊“cut!”）、录音乐（录制take 1，take2等）使用的术语]。在这些“C++教材”中，很多C++的重要特性都被作为一个小到令人乍舌的章节来介绍，活像影片中闪现不到半秒钟的色情镜头——想看的人心中大呼不过瘾，不想看的人则吃惊中带些厌恶。结果我当时几乎没学过异常处理的知识。现在国内外优秀的C++书籍多了，我才得以重新完整的学习C++。这一次，我可不能再学不伦不类的“C Remake++”语言了。
条款37. 经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；
[解说]：除了参考条款5之外，还想补充一点：本观点并不是想暗示大家应该对C++的各个方面内容一字排开并按某种顺序学习，而只是说明在不断学习提高的过程中，自己的实践经验也应该得到相应的积累。其实我觉得要把这件事做好，涉及到比想象中更多的事情，其中至少包括为自己的程序做文档以便于日后查看、重读。这件事真是说来容易做来难，我们还有很多需要努力的地方，不是吗？
条款38. 不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；
[解说]：同条款5。
条款39. C++语言和C++的集成开发环境要同时学习和掌握；
[解说]：见条款6。
条款40. 既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；
[解说]：这里说的“坚持”，绝不意味着迷信和狂热的崇拜（参见条款50），而应该意味着不浮躁，能够静下心来，扎扎实实打好基础。
[kingofark的收获]：抗拒浮躁的过程有一点点像憋尿，当然两者的结果和产生的影响大不相同。
[参考]：<K's 50 PV>条款50。
条款41. 就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；
[解说]：见条款6和条款9。
条款42. 当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；
条款43. 别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；
[解说]：古墓丽影（Tomb Raider）这个游戏想必大家都已经很熟悉了。当《古墓丽影：最后的启示（Tomb Raider : Last Revelation）》正式发行后，我和好友当然也乐此不疲的买了游戏光盘，和性感美丽的Lara Croft在3D世界中同甘共苦。事情就这样开了： 好友忽然有一天在电话中告知我说，Lara要与一个巨大的石头脸进行一种规则较为简单的格子棋游戏。棋盘是单向无环路的，有起点和终点；下棋双方每边各有三个棋子，通过随机的方式得到一定范围内的步数来走棋；正常情况下，每一方每次只有一次确定步数的机会并只能选一个棋子走棋；如果被移动的棋子在移动后停在某些特定的位置上，那就可以再走一次棋；特别的，如果得到的步数是某些特定的数字，则也可以再走一次棋；谁先把自己的三个棋子走完就算谁赢。我们讨论了半天，觉得这个简单的游戏可以很容易写出C++代码来，于是就开始做设计。虽然朋友很快就退出改玩游戏去了，但还是给了我很多建议。第一遍设计出来之后，我养成的种种坏习惯复发了。等到代码成形，里面已经充斥着杂乱的结构体和全局变量了。而且由于抽象的不合理，代码中处处都存在着重复的代码段。看着一堆垃圾般的代码，我的信心好像碰到异物的蜗牛触角一样刹那间飞也似的缩走了，。然而，不能接受“程序甚至还不能编译执行”这样一个事实的我不能释怀，只好硬着头皮继续写下去，越写越看出自己代码中的龌龊。结果当然是bug满宇宙飞，想修改都不容易了。只好作罢，继续自己每天正常的C++学习。若干个月之后，当我偶然从废纸堆中翻到那个bug.exe的原始设计草稿时，我又忍不住重新思考这个问题了。几个月的C++学习毕竟不是全没有作用，因此在充分认识到以前代码的缺陷的前提下，我的脑海里涌出了许多新思路，真所谓长江后浪推前浪……现在回想起来觉得，倘若当时第一次就半途而废，或许还不会对其中的不足之处有那么深的印象。这才发觉差劲的代码原来也是搞自我批评的重大阵营。
[kingofark的收获]：做什么事都不要虎头蛇尾。就连把坏事做一半所得到的教训，也不如把坏事做完得到的教训深刻。
条款44. 决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；
[解说]：参见条款26。
条款45. 每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；
[解说]：这个道理涉及到一些鲜为人知的一系列心理学、教育学方面的问题，我不在此累述。大家只用记住：转述的过程，也是人们常说的 “把知识变成自己的”之过程的一种表现形式。
[kingofark的收获]：题外话：有学问的老师未必讲课讲得好；讲课讲得好的老师未必有学问，但他/她总能把自己懂的那一部分知识讲清楚。我更喜欢后一种老师。
条款46. 记录下在和别人交流时发现的自己忽视或不理解的知识点；
[解说]：当你发现别人比你知道得多的时候，你不羡慕吗？不嫉妒吗？不敬佩吗？不崇拜吗？不自卑吗？不想超过他吗？随身带张纸，带支笔，并不会累死你的。
[kingofark的收获]：就算是天上真的掉下馅饼了，也还是需要你伸手去捡着吃的。如果你仅仅因为懒得伸手而不去吃，那可就比迷信“天上掉馅饼”的人还要可悲了。
条款47. 请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；
[解说]：同条款37。
条款48. 保存好你写过的所有的程序——那是你最好的积累之一；
[解说]：理由一：如果你不保存好，就无法遵守条款35，37，47了；
理由二：越来越多的代码多少会给人一种成就感，可以在不经意之间增强自信心。
[kingofark的收获]：理由三：万一自己以后出了名，还可以在电视直播或者自传里面把代码拿出来，作为训诫后人、为人师表的本钱，谱写一曲老当益壮的精神文明凯歌。
条款50. 请热爱C++!
[解说]： 请热爱C++，但是切忌蜕变成目光短浅的、迷信C++的狂热分子。
[kingofark最后的收获]：对C++说：“Everybody says I love you but no more.”
[K’s 50 PV 后记]：回顾这50条，揪心的发现其中有许多的重复观点，只是用了不同的表述而已。 这也与< K’s 50 PV>的成因有关。 最初是在CSDN的论坛上看到一篇人气颇旺的贴文，讨论些学习C/C++的经验，忽然使我有了对过去学习的感触，一些自己揣摩的文字猛然间如滔滔江水连绵不绝，又如黄河泛滥一发不可收拾，死心塌地、义无反顾的从脑海里泄将出来。 其实最后写出来的，无非是些众所周知的“耳茧增长因子”，全没有女人裸体见情人般的光彩。但自己还是不免浮躁的得意起来，淫笑着将这些文字发成贴子，收获了一次在公共场所署上自己大名的快感。等到我严肃得要给她写注解的时候，才很尴尬的注意到自己的无知与浅薄。于是很无能的继续写下去。这一次，便有了女人裸体见陌生人的尴尬——还是全裸。惭愧、羞愧一并涌上脸来，铁青。 无地自容。是以为记。 | 
转播
