1.代码是否要规范？答案是肯定的，代码就像是语言，是用来交流的传播信息的一种方式，只有做到统一书写，才能使人互相理解。但是到底什么是规范的代码？在我看来这也可以说是前辈们的经验总结，形成了格式清晰的代码规范；这是我们现在的所写的代码的规范要求，又有可能在未来会产生一种新的规范，我无法预测它是什么样的，但有一点我敢肯定那一定是更加清晰易懂的代码形式。若果有人非要以自己喜欢的格式打代码，我认为那种格式可以分为两种，一种就是懒得去按规范写，想换行就换行不想换接着写，想来当这种人写完代码自己回头去找错误改代码也会成为一种“挑战吧”，还有一种我觉得应该是比较有”强迫症“的那种，就算如今的规范代码形势也看不舒服，如实乎开始自创一种全新的规格，如果是一种能让人赏心悦目的代码也未尝不可吧。
其实打代码也是一种生活习惯，习惯好自然是让人们满意，习惯不好当然是没人喜欢。
2.代码复审
复审王林的代码，王林平时就是一个生活规律的人，从他的代码上也能看出这一点，代码是可以运行的，而且符合规范代码这一要求，唯一不足之处是没有在代码后面加上注释，代码上加一些适当的注释不仅可以让人看的更清楚，也可以方便自己对代码的改进，很多初学者都没有这个习惯我也是其中之一，我会努力养成在写代码的过程中加注释的习惯的。
3.PSP
| psp | Time（h） | |
|
Planning |
计划 | 4 |
|
Estimate |
估计项目需要多少时间 | 5 |
|
Development |
开发 | 4.1 |
|
Analysis |
需求分析 | 0.8 |
|
Design Spec |
生成设计文档 | 0.4 |
|
Design Reveiew |
设计复审（和同事审核设计该文档） | 0.3 |
|
Coding Standard |
代码规范（为目前开发定制合适的规范） | 0.2 |
|
Design |
具体设计 | 0.6 |
|
Coding |
具体代码 | 1 |
|
Code Review |
代码复审 | 0.5 |
|
Test |
测试（自测，修改代码，提交修改） | 0.3 |
|
Reporting |
报告 | 1 |
|
Test Report |
测试报告 | 0.3 |
|
Size Measurement |
计算工作量 | 0.2 |
|
Postmortem & Process Improvement Plan |
事后总结，并提出过程改进计划 | 0.5 |