上个月工作一直很忙，于是就很久没有更新博客了。今天早晨51CTO的博客管理员同学问了我一下，我也觉得是该继续写文章了。 我要先说说对待注释的态度问题。有一种不写注释的理由，叫做“代码是最好的注释”或是“好的代码应该是自解释型的”。这两个观点其实我都非常赞同，只不过，它们容易被人误用为不写注释的藉口。我们有理由质疑，那种胡乱拼凑瞎写出来的代码
写代码也流行注水了么？不是不是，我说的是注释。其实注释这个东西，历史久远。我们可以宽泛一点儿说，《春秋》就是要配上左传的注解，才能兴发其“微言大义”嘛！注释有很多种，如果按照注释者与原文作者是不是同一个人来分，可以划分成自注和他注。在程序员这个行当内，一般来说，还是自注多一些，自己写代码，自己加注。有的时候进行代码审查或者复用遗留代码时，才可能会有必要对他人写的代码加注
写了前三篇之后，发现比我预想的效果要好。关注代码质量的朋友还蛮多的，而且很多意见和建议也很有益，指出了我文章中的一些问题。 我这种家庭妇男型的自由职业者来说，在平常写代码的时候可以多停下来，思考一些代码质量与软件设计方面的问题。当然啦，由于具体的工作环境、关注领域、自身阅历等原因，小翔在文中提出的许多观点难免书生之见，请诸位多包涵。 针对排版这个问题，不同的公司、团队都有自己的一套
写完前两篇之后，有点小倦怠，因为一方面要整理读书笔记，一方面还要结合自己的思路加以重新表述，颇费周张。不过前两日看到有小朋友过来赞我的文章，说对实际代码有所帮助，还是满欣慰的，本系列随想录的目的之一，就是要营造一个努力改良代码质量的思维环境。 要想让标识符的名称更易理解，就应该多考虑考虑此名称是否会被误读。 先看两个很容易误读的例子。 Object[] resu
不必被我的标题吓到哈，孔老夫子时代没有电脑。如果有，估计诸子百家们还得针对软件工程抒发一系列代码质量伦理学的教条。 上回文章说到，代码品质改进应该在三个层面上展开，其中最微观的就是代码段的质量考究了。很多时候我在针对一些项目做工程分析和大规模重构之前，首先希望对大概的工作原理有些瞭解，这个时候就要深入核心模块的文件之中，挑选代码来阅读，以求理顺思路了。根据个人的经验来说，微观的改进往往能
一直以来想写点关于代码质量的心得，碍于自身的懒惰。今天终究找到一个提前忙完工作的午后，可以先让自己的思路开动起来了。 最终促使我开始整理自己对于代码质量的看法，还多亏了前阵子认识的Long小朋友，他及时地向我推荐了《The Art of Readable Code》这本书（下文简称ARC）。在看过了马叔叔的《Clean Code》和《Clean Coder》之后，这本书彻底让我沉迷于代码
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
