编程精粹读后感精选

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