《编程精粹》是一本由Steve Maguire著作,人民邮电出版社出版的256图书,本书定价:45.00元,页数:2009.2,特精心从网络上整理的一些读者的读后感,希望对大家能有帮助。 《编程精粹》精选点评: ●没看得太仔细但也领会到了精神学到了几个技巧,举例大多在讲指针和内存暂时用不到。接下去打算试用PC-Lint检查一下程序,有空的时候再花些时间啃啃那些例子和练习后补一颗星。 ●第一次看的时候在上班期间大致地 ●微软四大名著之一,与《代码大全》齐名的一本书 ●内容略老但仍不失经典。 ●被人忽略的经典书籍,也是教会程序员如何用正确的方式做事情. ●看过电子书,董老师鼎力推荐~ ●经典的老书。这类书读的比例有点大,没新鲜感了,早先知道这本书就好了。 ●浏览了一遍 ●虽然我读的是中文版……小屏幕绿底下一行行读完勒…… ●注重对错误的处理 《编程精粹》读后感(一):只是小部分程序设计tricks 刚买这本书的时候对他的期望还是很高的,看完之后,有了些失望。讲思想感觉这本书不如程序员修炼之道,讲具体的编码细节不如代码大全。豆瓣评分居然有9分,感觉还是有些过的,与前面两本书的层次还是有些差距的。 这本书中最独特的视角可能就是作者的那些错误代码的分析了,不过其中的例子也不是很多。第一章是用编译器预警、第二章是断言、第三章是subsystems、第四章是step through,后面的几章关注的都是一些极其特殊的情况(over flow、portable等问题)可能做产品需要,但是平常的编程数据处理基本用不着。 现在感觉代码大全可能真的是经的起检验的书了 《编程精粹》读后感(二):原书应该是1993年出版的。对这样一本书,应该既批判又继承的加以消化。 写明是人民邮电出版社2009年出版的,但我怀疑原书应该是1993年的——差不多20多年前的一本书。我到www.amazon.com上搜索writing solid code,只找到一本,正是1993年的。 那么问题就来了,今天读这本书,是不是要用一些批判的眼光:毕竟经过近20年的发展,编程的方方面面也发展了一些显著或微妙的变化。批判的同时,汲取其中对于编程一般规律的阐释。 这就是我在开始阅读它之前的一些简单思考,也希望能提醒广大书友。因为读书本身并不是目的,吸收、借鉴书中有用的观点并拿来指导实践才是读书的初衷。 《编程精粹》读后感(三):我读过的第一本原版技术类书籍 《代码大全》也在我的当前阅读列表中停留了三四年了。天幸最近两年的阅读速度有了很大的改进。终于把这本书先pass掉了——其实加起来可能就用了有30个小时? 这本书和《代码大全》的定位是一致的。但是感觉它并没有非常系统地写完美。比如前几章还能寻出脉络,但是后几章完全是各种知识的杂烩。没有明显的逻辑关系。 不过,在这本书前,我曾经一度觉得我自己已经可以很完美地翻译一本技术类的专业书,但是,这本书中,有某些地方,我觉得还是有一定的小困难。 对于求职和在校的学生,或者阅读能力不太好的同志们。建议把重心仅仅放在代码大全上即可。这本书并非非读不可。我觉得代码大全的覆盖面会更广。 但是,仍然要说但是,这本书对于某些类别的bug的分析是有价值的。但凡有能力读,都可以用心把它读过来一遍。 最后,我想说,读英文原版是有价值的。有些描述,中文里看起来可能是套话,但是英文的描述,可能会激发你思考。这一点在我现在看的英文版格林童话里体现地尤其明显。中文的一个故事,读过了,那些句子你很可能会从脑海里滑过去。 《编程精粹》读后感(四):一本肝肠断 一本谭浩强的《C语言程序设计》将一个少年引入了奇妙的C语言世界,从此为之疯狂。 之后接触的《C和指针》、《C陷阱与缺陷》、《C程序设计语言》…无一不是C语言世界里的巨作。但是,这本《Write Solid Code》实在是令人震撼,与《程序设计实践》一样,作为一个程序员,您不得不看! 这书并没有教你如何写代码,而是如何写正确的Bug-free的代码。本以为C语言标准库中的代码无懈可击,但是书中却对relloc函数大加批评,如此酣畅,如此淋漓。确实,这是一个很risky的函数。回头看以前自己写的代码,心中不免一阵厌恶,简直就是rubbish!。而更令自己恶心的是,对这些rubbish还觉得可以,无知真是相当的可怕。 《Write Solid Code》,一本肝肠断呐。 《编程精粹》读后感(五):用这些朴实的习惯写出易排错的代码… 都是一些比较实用的习惯,能让程序的健壮性更强。 1. 断言真的是很实用,能查出一些意外的bug。这点感触比较深,插入一些必要的断言,这样不至于在程序执行N久以后才恍然发现在前面N远处一个参数什么的传错了。,而且几乎不会影响性能。关于断言的使用也有一些注意事项(在《卓有成效的程序员》等书里都有提到),比如:assert(getchar() == "c");这个断言就影响了程序本身。 2. 对程序进行逐条跟踪。正如作者所说,有可能在逐条跟踪的时候觉得是浪费时间,但这能对这段代码的正确性有很好的把握(至少不会出现提交程序后别人再check 下来的居然编译都不过!),减少不少以后调bug的时间。 3.要注意程序语言里未定义的行为,如对于c里的函数memcpy,当dest~dest+size和 src~ src+size 这两段区间如果有交集的话,结果是未知的。 4. 边写代码边测试。(或者现在流行的测试先行?) 5. 关于程序员和测试员。"程序员测试代码,是从里向外测试,而测试员则是从外向里测试。" 程序员对自己的代码更了解,所以自己通过多加断言等方式测试自己的代码是很有必要的。 6. ...... ....... 当然这很多的习惯都要在编码中才能有更好的体会。"临渊羡鱼,不如退而结网"。