代码大全读后感 第2篇

  为变量命名时最重要的考虑事项是,该名字要完全、准确地描述出该变量所代表的事物。

currentDate和todaysDate都是很好的名字,因为它们都完全而且准确地描述出了“当前日期”

这一概念。事实上,这两个名字都用了非常直白的词。程序员们有时候会忽视这些普

通词语,而它们往往却是最明确的。cd和c是很糟的命名,因为它们太短,同时又不具有

描述性。current也很糟,因为它并没有告诉你是当前的什么。date看上去不错,但经过最

后推敲它也只是个坏名字,因为这里所说的日期并不是所有的日期均可,而只是特指当前日

期;而date本身并未表达出这层含义。x、x1和x2永远是坏名字——传统上用x代表一个

未知量;如果你不希望你的变量所代表的是一个未知量,那么请考虑取一个更好的名字吧。

 名字应该尽可能地明确。像x、、i这些名字都泛泛得可以用于多种目的,它们并

没有像应该的那样提供足够信息,因此通常都是命名上的败笔。有人也许会反驳说,把

i用作循环下标是最正常不过的了,难道非得写成indexOfTheLoop这种又臭又长的名字才算

好吗?Steve McConnell认为,如果循环只有寥寥数行,而且只是单层循环,那么用

i是也是可行的。不过试想一下,如果你一直习惯用i作循环下标,

而你将来可能需要把这个循环放到另一个循环中去执行,即循环嵌套,

那么内外层循环都用i作下标肯定是不行的。如果编译器提醒你说变量

i重复定义,那还算走运;如果编译器默不作声,而你自己又忘了修改,

呃,你听见虫子飞舞的声音了吗?由于代码会经常修改、扩充,或者复制到其他程序中去,

因此很多有经验的程序员索性不使用类似于i这样的名字。如果循环不是只有几行,

那么代码阅读者会很容易忘记i本来具有的含义,因此最好给循环下标换一个更有意义的名字。

导致循环变长的常见原因之一是出现循环的嵌套使用。如果你使用了多个嵌套的循环,那么就应该给循环变量赋予更长的名字以提高可读性:

 for (int teamIndex = 0; teamIndex < teamCount; teamIndex++)

   for 

   (int eventIndex = 0; eventIndex < eventCount[teamIndex]; eventIndex++)

  { 

        score[teamIndex][eventIndex] = 0; 

   } 

谨慎地为循环下标变量命名可以避免产生常见的下标串话(index cross-talk)问题:

想用j的时候写了i,想用i的时候却写了j。同时这也使得数据访问变得更加清晰:

score[teamIndex][eventIndex]要比score[i][j]给出的信息更多。

 如果你一定要用i、j、k,那么不要把它们用于简单循环的循环下标之外的任何场合—

—这种传统已经太深入人心了,一旦违背该原则,将这些变量用于其他用途就可能造成误解。

要想避免出现这样的问题,最简单的方法就是想出一个比i、j、k、更具描述性的名字来。

 变量名的最佳长度似乎应该介于x和maximumNumberOfPointsInModernOlympics

之间。太短的名字无法传达足够的信息。诸如x1和x2这样的名字所存在的问题是,

即使你知道了x代表什么,也无法获知x1和x2之间的关系。太长的名字很难写,同时也会使得程序的视

觉结构变得模糊不清。当研究发现,当变量名的平均长度在10到16个字符的时候,

调试程序所需花费的气力是最小的。平均名字长度在8到20个字符的程序也几乎同样容易调试。这项原则并不意味着

你应该尽量把变量名的长度控制在9到15或者10到16个字符。它强调的是,如果你查看

自己写的代码时发现了很多更短的名字,那么需要认真检查,确保这些名字含义足够清晰。

 

时间: 2024-10-05 05:31:18

代码大全读后感 第2篇的相关文章

代码大全读后感 第3篇

<<代码大全>>第31章专门介绍代码的布局与风格,前面提到过,编码规范最有用之处 在于让你避免做出武断决定,避免把时间花在无谓的争执上(第34.5节).McConnell 并不像一位“家具警察”那样对待代码的格式,他认为好的代码布局应凸现程序的逻辑结构, 使代码易于阅读.理解.检查及修改.至于循环体应该缩进几个空格,大括号的摆放位置这 些问题,正确答案不止一种.每次回答同样内容比起只是回答正确更重要.第28.5 节谈到了程序员的信仰问题,缩进风格.大括号的摆放位置.注释风格.命名习

代码大全读后感 第1篇

在王老师的推荐下,我在1个月左右时间内大略读完此书.感觉确实受益匪浅,感受颇多.此书英文名叫:code complete ,诚如书中译序所说,这本书讲的正是为了到达“编码完成”这一重要里程碑所需的软件构建技术,确切地说,就是如何编写高质量的代码. 高质量的代码既可以说是一个节省成本的问题,也可以说是一个软件安全性的问题.特别是针对金融行业的软件开发者而言, 提高软件质量显得尤为重要.为了使我们能够编写出高质量的软件,书中讲述了软件构建的 方方面面,详细讨论了源代码的可读性,类和函数命名.变量命名

代码大全读后感(1)

经老师推荐,开始看<代码大全>看完前面觉得有很多值得回味的地方,而且每部分之后作者还推荐了不少经典书籍.在这,作个读书心得.全书的主题是软件构建,大致看了一下目录,关于软件构建问题的方方面面均有涉及,共分7个部分,从软件构建前期准备,到语言层的一些问题,再到代码完善,系统考虑以及软件工艺等等.以下分别进行简单说明. 第一部分是打好基础,本部分主要是软件构建前期的工作,以及对一些基本概念的介绍,具体包括如何选择编程语言和构建实践方法,如何理解软件开发的过程.软件开发本质上说就是工程,书中用建筑工

代码大全读后感(二)

写代码首先要搞清楚面向对象,不是为机器编写代码,更重要的是沟通,人们可以看懂不是自己写的代码的思路.问题,方便修改. 毕竟自己写的代码只要正确机器一般都能看懂识别,但是别人就不一定了,势必考虑异常的出现.从马士兵老师开始,就告诫我们得把你的用户当魔鬼,魔鬼是不会像我们想象中那样去使用我们的程序的.本书的防御式编程也重申了这点,人是会犯错的,毋庸置疑,重要的是犯错后你怎么抛异常.控制错误的影响范围和补救措施.为人写代码,势必要将代码写的漂亮.你看印在书里的文章,所有的文字都用标点符号分隔,行与行有

代码大全读后感(2)

本书的第三部分是变量(我总是搞不懂),这是全书描述的最细微的单元.主要包括如果对变量命名,变量与数据的绑定时间,基本的数据类型以及一些不常见的数据类型,比如指针.全局变量等等.变量命名是有多种方法的,用哪种无所谓,关键是要统一.变量与数据的绑定时间,这个问题我以前没有系统考虑过.书中的观点是绑定时间越滞后,则系统越灵活.这个我赞同.硬编码到程序中的,是直接赋予数值的常量,除非修改源码,否则不变:编译时刻确定的,是一些静态变量:运行时间确定的,就难说了,可能是从I/O获得,也可能是从内存获得.其它

代码大全读后感(3)

接着我看了第六模块,第六部分是系统考虑,这部分是对软件管理方面的考量,具体包括程序规模对构建的影响,如何去管理构建过程,如何集成模块,以及介绍软件构建的工具.这部分内容像是给Manager准备的哈,现在的我,需要在多个项目中逐步体会. 第七部分,讲述软件工艺.软件说到底,也就是一个产品,只不是产品的形式与一般不同.一部分是构建出来的可执行程序,一部分是完整的软件源码.对于源码的书写,就涉及到工艺了,不同层次的人写出来的代码是完全不一样的.水平高低暂且不论,单是注释的规范整齐程序,就可见一斑.这部

代码大全读后感(三)

粗略的读完之后会发下这是一本完整的软件构建手册,涵盖了软件构建过程中的所有细节.它从软件质量和编程思想等方面论述了软件构建的各个问题,并详细论述了紧跟潮流的新技术.高屋建瓴的观点.通用的概念,还含有丰富而典型的程序示例.这本书中所论述的技术不仅填补了初级与高级编程技术之间的空白,而且也为程序员们提供了一个有关编程技巧的信息来源.这本书对经验丰富的程序员.技术带头人.自学的程序员及几乎不懂太多编程技巧的学生们都是大有裨益的.可以说,无论是什么背景的读者,阅读这本书都有助于在更短的时间内.更容易地写

《代码大全2》读后感czz

经老师推荐,买了一本<代码大全2>,花了近3个月的时间看完了,看完后觉得还有很多值得回味的地方,而且每部分之后作者还推荐了不少经典书籍.所以,作个读书心得.全书的主题是软件构建,关于软件构建问题的方方面面均有涉及,共分7个部分,从软件构建前期准备,到语言层的一些问题,再到代码完善,系统考虑以及软件工艺等等.以下分别进行简单说明. 第一部分是打好基础,本部分主要是软件构建前期的工作,以及对一些基本概念的介绍,具体包括如何选择编程语言和构建实践方法,如何理解软件开发的过程.软件开发本质上说就是工程

《代码大全》读后感

最近买了几本经典编程书,有<head first 设计模式><人月神话><程序员修炼之道><代码大全>,<代码大全>是第二本看完的. 看的期间不断有所悟,书中多处让我惊讶「原来是这样子」.不过由于工作之余时间有限,这本大著看了快两个月才完了,现在仅凭印象把之前悟到的写下来,算是总结. 如果要用一句话概括<代码大全>的话,我以为是「为人写代码,而不是机器」. 一:为人写代码,势必要考虑代码的扩展性.人是多变的,现实世界也是多变的,所以写