《代码之髓》经典读后感10篇

　　《代码之髓》是一本由[日] 西尾泰和著作，人民邮电出版社出版的平装图书，本书定价：45.00元，页数：236，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

　　《代码之髓》读后感(一)：为什么要有名字，为什么要有类型？

　　为什么要取名：

　　最初是“给3456号的数值加一”后来人们觉得应该给内容或者位置取一个容易理解的名字。相比于“取出ISBN编号是978-123-4857-293的书”，“取出《Python程序设计》这本书”更人性化一点。

　　while语句是让反复执行的if的判断更加简洁。for语句的出现是让while语句变得更简洁，

　　为什么要有类型：

　　因为不同形式的数据的存储形式不同，拿简单的数字来说吧，有定点数和浮点数，定点数的存储的二进制形式如果看作是浮点数那就相差极大。所以要定义类型，不同类型的数据之间做运算也很复杂。

　　如果是整型，x/2的小数点后面的数据就应该舍去。但是对于浮点型，不舍去。Python中x/y是不舍去的运算，而x//y设计成舍去的。

　　静态变量和动态变量：动态类型在LISP中应用，Python中也借鉴了。把类型的信息和数值看作整体的方式叫做动态类型。

　　ython中不管是整数还是浮点数还是字符串，都看作是pyObject对待，开始部分都是一样的。

　　实数：

　　使用次数＋值的类型[浮点数]＋值[浮点数值]

　　字符串：

　　使用次数＋值的类型[字符串]＋大小＋散列值＋状态＋第0个字符＋第1个字符...

　　各种各样的容器：

　　在不同的语言中，容器的名称不同，性质各异。比如，C语言中的数组、LISP中的列表、Python语言中的元组以及Ruby语言中的数组。即使是名字相同，在不同语言中表达的意思也可能不一样。比如，LISP语言和Haskell语言中的列表，与Java语言和Python语言中的列表在内部构造上完全不同。不同语言中名称的差异是导致混乱的根源。LISP中的列表指链表，有时候单说列表指的就是链表。而Java语言中的列表(java.util.List)则是一种有能放入多个元素的功能的接口。java.util.LinkedList<E>就变成一种链表，这和LISP语言中的列表概念就比较接近了。元组也是表示能放入多个元素的东西，但Python语言中的元组和Haskell语言中的元组的共通点就很少。Python语言中的元组是不可变更的列表，而Haskell语言中的列表本来就是不可变更的。Haskell语言中的元组是可以存放不同类型数值的列表，而Python语言中的列表本来就可以存放不同类型的数值。Ruby语言中的数组(array)是“数组类”，具有C语言数组没有的很多功能，反而更加接近Python语言中的列表的概念。

　　数组和链表

　　如果同一个容器放入相同的三个数据A、B、C，数组中，三者是顺序存放的。链表(Linked List)中存放A的数据的下一个箱子还存放有下一个值在何处的信息。存放C的数据的下一个箱子存放的是0，表示没有下一个值了。

　　乍一看，链表这种数据存放的方式要消耗两倍于数组的内存。但是长处也是很明显的，如果要在A和B中插入数据Z，数组必须把整个数据复制一遍，这对于数据量相当大的数据比如100000个元素，工作量就相当大了。

　　但是对于链表，只需要把A的下一个箱子的位置指向Z数据的地方，这样就结束了。

　　链表的长处和短处：

　　对于插入和删除数据，链表的计算量是O(1)，读作常数的数量级，或者常数时间，即如果处理的数据量n翻倍，计算所花费的时间不变；而数组是O(n)，即n的数量级，也称线性时间，如果数据量n翻倍，计算所花费的时间也翻倍。

　　链表也有短处。数组中存放方式是固定的，因此容易找到第n个元素，找相应的数组，在哪儿开头，相应的加上元素的下标，就是对应元素的位置，计算量是O(1)；链表中的元素可以放置在任意喜欢的位置，因此必须从头找起，找每个元素，指向下一个元素，这样计算量是O(n)

　　字典：

　　数组是整数和值的对应，当问到第10个数值是多少时，它能告知第10个数值是3.

　　字典是字符串（或者其他类型）与数值的对应，被问到“age”对应值是多少，告知“age”值是31.这里的字符串被称为字典的键。例子是对于一个人，有这么一些信息，name=Taro, age=31, score=80 ...

　　对于字符串与值的对应有多种实现形式，常用的方法是散列表和树。例子，有三个小孩，Ichiro, Hanako and Jiro, age: 5, 4, and 3.

　　散列表：

　　通过散列函数，将字符串和一个数值对应，这个数值表示了字符串对应的值（age）所在的位置。再把数值（age）放在相应的位置。

　　树：

　　left right Ichiro 5

　　↙ ↘

　　left right Hanako 4 left right Jiro 3

　　以Ichiro为根，放入其值，再判断Hanako，在其左边，left的空格指向Hanako，再追加Jiro元素，右边的空格指向Jiro，如果还有其他元素，放在Hanako的下面或者Jiro下面。

　　树的优势：

　　数组找一个元素，要么第一个，或者最后一个，平均期望是n/2, 复杂度O(n)

　　而树要做到两遍平衡，就能实现二分查找，复杂度O(log n) 二叉树或者红黑树的平衡也是个研究问题。

　　散列表的优势：

　　只需要把字符串转化为数组的位置信息，再在该位置读取出这个值，复杂度O(1)

　　散列表需要时间数量级最小。内存方面看，数组方法占用内存最小，散列表需要很大的数组，内存占用最大。

　　没有万能的容器，需要权衡复杂度（处理数据量的时间）和内存和数据量的大小。

　　字符：

　　莫斯码、ASCII码、乱七八糟各种码。统一在于Unicode

　　编辑器比如Vim和Emacs，用记号实现声明该文件的打开方式，称为魔幻注释符：

　　# -*- coding: Unicode UTF-8 -*-

　　字符串：字符并列的结果

　　C语言不知道自身的长度，其他Pascal、Java、Ruby和Python几种语言都能知道自身的长度，C语言字符串是最原始的字符串。

　　C语言表示该字符串的结束，使用NUL字符，是一种与0对应的字符，C中用\0表示。可能会产生奇怪的错误。"abc\0efg"只显示前三个字符abc，而设定内存为3的字符串char放入“abc”因为没有后面的\0，在输出的时候，会和后面的字符串纠结在一块输出。

　　并行处理：同时使用音乐，浏览器和字符处理软件。

　　在一个CPU的情况下如何并行：极短的时间内，交替处理任务。交替的两种方法：

　　协作式多任务模式：

　　在合适的节点自发地进行交替。有可能某个处理一直找不到合适的节点进行任务切换而持续地进行，导致其他处理无法等到执行的机会。Windows3.1和Mac OS 9都是协作式多任务系统。以后就改进了

　　抢占式多任务模式：

　　有一个比其他程序都有优势的程序任务管理器，在一定时间后强制中断正在进行的处理，以便允许其他程序的执行，能在人们察觉不到的中断时间比如20毫秒或0.02秒实现交替。

　　《代码之髓》读后感(二)：编程语言核心概念

　　编程语言核心概念,这就是本书的原标题,我想代码之髓一定是中文编辑后来画蛇添足加上去的.

　　编程语言本身已经走过了很长的发展里程,经过了摸索化,实践化,理论化,理论实践化等很多个阶段.在现在的时代,已经呈现出过度复杂化,过度概念化的倾向.

　　如果我们不能够追根溯源,从历史里面把握住语言中的核心概念是如何出现的,各自解决了什么最根本的问题,那么我们就会迷失在当下看起来一派繁荣的语言森林里面.

　　本书就是做这个去粗取精,寻根究源的工作,让我们重新认识语言中这些如此重要的概念的缘起,有了这个根本性的认识,我们就会知道,哪些是根,哪些是枝子,哪些是花.

　　而且特别难能可贵的一点是,作者一点也不故弄玄虚,从理论中来,但是并不用理论唬人,只用特别简单的,朴素的话来讲这些概念,特别好.

　　以上.

　　《代码之髓》读后感(三)：非常好的程序语言通识读本

　　从“编码”（コーディング）到“编程”（プログラミング），这个名词的小小改变，其实凝结了人类的许多智慧和心血。而这其中最重要的大发明，就是程序语言。人类擅长的是用语言交流，所以发明了各种各样的语言，这么一来人类就可以用自己熟悉的语言来编写程序，而不必直接去编写只有机器才能识别和执行的代码了。

　　编程语言发展到今天，已经经历了好几代，从种类上看更是有数千之众。这些语言当然不可能都为着同样的目标而被设计出来，所以它们之间的差异还是非常大的。这些差异性体现在诸多方面，语法的差异非常显著，而相似的语法背后的语义差异则更是无形而且微妙。如果考虑到语言的运行环境、应用领域，还有语言之上建立的方法论，更是让人感觉：难道在程序语言这个完全由人类创造的领域，也要出现像自然语言一样的，把程序员分成无数宗派甚至族群的“巴别塔”了吗？

　　其实不然，程序语言毕竟是工程学产物，它的发展其实是有着统一的计算模型作为背景的，因而可以视为一种“约束下的发展成果”。计算模型落实为实际计算机的体系结构，种类并没有很多。因此，建构在其上的程序语言，由于最终还是要落实为在这些体系结构之上执行的代码，结构和实现上不会完全失控。但话说回来，要写作一本关于程序语言的通识读本，能够在一本书里讲清楚程序语言的共性，并能够指导具体语言的学习，这件事还是很困难的。很容易就会写成建立在编译原理基础之上的大部头，这么一来对读者的要求就非常高了。还容易写成各种语言混在一起的大杂烩，把读者搞得晕头转向。更何况，如果真拿具体的语言来讲，现在的语言版本更新迭代速度很快，写成的书很快就过时了。

　　但是本书就很不一样，它抓的点非常好，是一些通用但是不会过时的点。这些点从程序结构来说，包括了名字和作用域（哪种语言会没有名字和作用域呢？）、函数、类型、异常处理；在库的方面，讨论了字符串和容器；从运行环境来说，讨论了并行处理；从方法论的角度，讨论了至今仍然是主流的OOP和类继承。每个主题都是既深入浅出，不停留在概念层面，又点到即止，避免纠缠技术细节，显示了日本工业界务实而又认真的做事态度，以及不俗的技术实力和表达能力。

　　我尤其喜欢第一章提出的两种程序语言的学习思路：在比较中学习，在历史中学习。从每种语言的独特语法结构中，我们能够体会到这种语言针对的特定问题领域的难点和特色，这也引导着我们提出新的问题，或者在不同领域的问题之间建立关联。而从那些从属于不同时代语言的代际比较，我们更可以同时体会到早期语言的强大和不足之处，以及新生语言做了哪些取舍（一定有舍，不可能只有改进，因为结果是一样的）来向哪些方面做了妥协。其实在学习自然语言的时候，这两个办法也是非常管用的，只是学习多种程序语言的人比学习多种自然语言的人要多得多而已。一开篇就开宗明义地提出语言学习方法，这也决定了本书的高度。

　　总之，非常好的一部程序语言通识读本，向所有同行推荐。

　　《代码之髓》读后感(四)：挺精致的一本技术书

　　这本书小巧精致，不像一般的计算机书那样的大块头，装帧和排版都很有美感，感觉像一本文艺书而不是技术书。闲暇时翻上几页，惬意而有所得。

　　内容由日本专家所著，正文不多但引注很多，有时一页的内容引文说明要占一小半，足见作者所做研究是充分。书中涉及到了多个语言的一些特性，在互相对比中让人了解其共通点与独特性，开阔了视野。同时穿插介绍一些语言产生及发展过程中的小故事，这又为枯燥的技术叙述增添了一点小趣味。

　　翻译得也还可以，读起来比较流畅，略有疑议的是第十章的“并行处理”可能翻译为“并发处理”比较好，从内容上看应该说的是并发（国内操作系统书籍一般都用并发这个词来表达多个程序轮流使用cpu资源的情形）

　　《代码之髓》读后感(五)：干劲是宝贵的东西！

　　FORTH on browser

　　LISP on browser

　　EDSAC on browser

　　书上的代码

　　Github

　　https://github.com/nishio/learn_language/tree/master/langbook#readme

　　感受，作为一个真·没见过世面的自学爱好者，

　　我真的被作者写得这三个东西惊艳到了，

　　好厉害！好厉害！好厉害！

　　《代码之髓》读后感(六)：程序设计语言的明朝那些事儿

　　花了一整天看完了。

　　就一个词：舒畅。

　　作者不假定读者有任何的计算机基础。按照各类语法的发展历史细细道来，为什么有这个概念，背后的权衡是什么，xxx的提出为了解决-xxx的什么问题。麻雀虽小，五脏俱全。正如作者所说的“在历史中学习”。

　　看完这本书，就可以看实践之路了。

　　并行应译为并发。还有，作者估计更偏爱perl语言。