养成好的生活和学习习惯

叁歲伎倆 2022-05-15 11:16 257阅读 0赞

\[生活习惯\]

社会的生活分了很多层次，过着哪种生活都要有一个好的习惯，有时候是一个好的习惯决定了你过哪一种生活。

一个好的习惯可以改变人的一生，一个坏的习惯也可以改变一生。

谈论到好坏习惯我们可以想到很多，比如平时不注意生活作息时间不规律，生物钟颠倒，吃喝嫖赌抽，好的习惯与此正好相反，这里指的习惯范围要更广一些，不仅仅指行为上，还包括思想上/思考/想问题/价值观等，都可以分出好与坏，而有时正式一个人的思想/价值观/考虑问题方式决定了他（她）最后的生活习惯。

好的习惯不是一两天就可以养成的已经成为了一条定理，它需要一个漫长的过程，经历艰苦卓绝的困苦，才可以改变，需要一点一点去改变，如果你不能改变坏习惯，那么你可以试着去按好习惯去做，取其精华，去其糟粕，不要等到坏习惯一大堆，要不黄花菜都凉了。

\[学习习惯\]

学习和生活是分不开的，想学习好了先要生活好，我们学习计算机，编码，画图等都要做到规范化，标准化，如写代码时不加注释就是一个损人不利己的事，我们写代码的目的是给别人看的，代码的读者不仅仅是自己还有别人，不写代码注释的后果有时是很严重的，你写的代码没有注释，等到你离职或走了之后别人看不懂你的代码就没办法就行修改，如果有问题了只能重构了，重构是相当麻烦的，有时重构也不能够解决，后果不堪设想啊。

这也是不够专业的表现，作为IT行业的一个成员，一个微不足道或举足轻重的成员，不加上注释也代表了你还不够专业。

无论对于编程还是其它工作都有自己的工作标准，按着标准做也是一种职业素质，既然这是我们的工作，我们就应该把它做好，要按着编程标准要求自己，要求别人，严格律己，宽以待人。

建议以后写代码时应当做到这样，在写代码的时候并完成注释，代码在注释在，做到剑在人在剑毁人亡，这也是人剑合一的最高境界，不仅仅要这样做，当代码更新后注释也需要更新，不然，写的注释就没有意义了，不要为了写注释而写注释，也不可啰啰嗦嗦瞎掰一大堆，要写的通俗易懂/简明扼要，可以被大多数人理解，正确反映出代码的意思。除此之外，再更新代码时一定要记的更新注释啊，做到代码与注释的同步。

当然，学习习惯不是仅指注释，拿写注释来作为一个例子参考，干其他的任何事情都要严格按着工作规范，软件工程思想来作。

写代码注释的一些建议：

#### 写好程序注释的十三条建议 ####

**1. Comment each level（每个级别的注释有统一的风格）**

注释每一个代码块，并且在各个级别的代码块上，要使用统一的注释方法。例如：

*  对于类，应包含简单的描述、作者以及最近的更改日期
 *  对于方法，应包含目的的描述、功能、参数以及返回值

使用统一的注释规则对于一个团队是非常重要的。当然，更加推荐使用注释的约定和工具*（例如，C\#的XML或Java的Javadoc）*，它们会是注释变得更加容易。

**2. Use paragraph comments（对段落注释）**

将代码块分成若干完成独立功能的“段落”，并在每个“段落”前添加注释，向读者说明“即将发生什么”。

// Check that all data records

// are correct

foreach (Record record in records)

if (rec.checkStatus()==Status.OK)

. . .

// Now we begin to perform

// transactions

Context ctx = new ApplicationContext();

ctx.BeginTransaction();

. . .

**3. Align comments in consecutive lines（对齐注释行）**

对于拥有后缀式注释的多行代码，排版注释代码，使各行注释对齐到同一列。

const MAX\_ITEMS = 10;  // maximum number of packets

const MASK = 0x1F;  // mask bit TCP

一些开发人员使用tab来对齐注释，有些则使用空格。但是由于tab在不同的编辑器或者IDE上会有所不同，最好还是使用空格。

**4. Don't insult the reader's intelligence（不要侮辱读者的智商）**

不要写没用的注释，例如：

if (a == 5)  // if a equals 5

counter = 0;  // set the counter to zero

写这种无用的注释不但浪费你的时间，而且读者在读这种很容易理解的代码时，很容易被你的注释转移注意力，浪费了时间。

**5. Be polite（要有礼貌）**

不要写不礼貌的注释代码，例如“注意，愚蠢的使用者输入了一个负数”，或者“修正由于最初的开发者的可怜且愚蠢的编码所造成的副作用”。这样的注释冒犯了作者，而且你并不知道谁会在将来读到这段注释——你老板、客户或者是你在注释中冒犯的那个可怜且愚蠢的开发人员。

**6. Get to the point（简明扼要）**

不要在注释中写的过多，不要写玩笑、诗和冗长的话。总之，注释需要简单直接。

**7. Use a consistent style（风格一致）**

一些人认为注释应该能让非程序员也能看懂，但是也有些人认为注释仅仅是指导程序员的。不管怎么说，像《Successful Strategies for Commenting Code》中所说，真正重要的是注释始终面向同一个读者，在这点上，应该保持一致。个人认为，我很怀疑会有非程序人员阅读代码，所以应该把阅读注释的对象定位为开发人员。

**8. Use special tags for internal use（在内部使用特殊的标签）**

团队中处理代码时，在程序员之间应采用一系列统一的‘标签注释’进行交流。例如，很多团队使用“TODO”来表示一段需要额外工作的代码。

int Estimate(int x, int y)

// TODO: implement the calculations

return 0;

‘标签注释’并不解释代码，而是引起主意或者传递信息。但是，使用这种方法时，务必要完成‘标签注释’传递的信息。

**9. Comment code while writing it（写代码的同时，完成注释）**

写代码的同时添加注释，因为此时你的思路最为清晰。如果你把注释的任务留到最后，那么你相当于经历了两次编码。“我没有时间注释”“我太忙了”“项目耽误了”这些往往是不写注释的理由。所以，程序员们认为，最理想的解决方法是‘写代码前先写注释’。例如：

public void ProcessOrder()

// Make sure the products are available

// Check that the customer is valid

// Send the order to the store

// Generate bill

**10. Write comments as if they were for you (in fact, they are)把代码的读者想象成你自己（实际情况往往如此）**

注释代码时，不仅仅要为将来可能维护你代码的人考虑，而且要考虑到读注释的可能是你。伟大的Phil Haack说过：“每当有一行代码被敲上屏幕，你都要从维护的角度审视一遍这段代码。” "*As soon as a line of code is laid on the screen, you’re in maintenance mode on that piece of code.*"（著名的话不敢不附上原句）

结果，我们自己往往是我们良好注释的受益者，或者是烂注释的受害人。

**11. Update comments when you update the code（更新代码时，记得更新注释）**

如果不能随着代码的更新而更新注释，那么即使再准确的注释也毫无意义。代码和注释必须同步，否则这些注释对于维护你代码的程序人员来说简直是折磨。在使用refactoring工具自动更新代码时，应尤其注意，它们会自动更新代码而不会改变注释，这些注释自然就过期了。

**12. The golden rule of comments: readable code（可读性良好的代码是最好的注释）**

对于许多程序员来说，基本的原则之一就是：让代码自己说话。有人可能会怀疑这是那些不爱写注释的程序员的借口，然而这确实是一个不争的事实。自我解释良好的代码对于编码来说大有益处，不但代码容易理解甚至使注释变得没有必要。举例来说，在我的文章《Fluid Interfaces》中展示了什么是清晰的自我解释型代码：

Calculator calc = new Calculator();

calc.Set(0);

calc.Add(10);

calc.Multiply(2);

calc.Subtract(4);

写好代码不是我们的目标，但这是基础中的基础，只有基础做好了，我们才能走的更远！！