我的观点：
- 对于程序员来说，代码规范太繁琐不好，但也不能没有，规范的最低限度是公认的C#开发规范；
- 代码规范存在的目的应时刻铭记于心，这样程序员才能顺其自然的遵守；
- 规范有助于降低重构难度，而困难的重构往往会导致bug；
- 不断重构，不断成长；
代码维护的困局。产品不断演近和业务调整，需要程序员对代码不断维护，对于一个趋于成熟的产品而言，代码维护基本上算是程序员的主要工作。但为什么有时这项工作让我们举步维艰，bug百出呢？（代码雷区）人员的流动是原因之一，毕竟同样代码的维护人员可能不止一个，更深层次的原因则是我们写了不恰当的代码，给后来者（包括自己，比如代码是三个月前开发的）埋下了雷。这时候你心中暗骂的同时是不是期望当初有个规范约束程序员肆意书写呢？维护还得继续，是继续肆意书写代码，还是重构为将来的维护降低难度，这真的是一个问题。
为何要有规范？ 程序员至少应该遵守最低限度的规范，即C#开发规范，这点毋庸置疑，它的内容包含基本的命名规范，大小写等。一般来说，能遵守C#开发规范的程序员已经可以写出比较清爽的代码了。而对于不同开发团队，规范则是团队内开发习惯和有效经验的总结，每个团队的成员都应该遵守，还记得之前提到的代码雷区吗，不恰当的代码往往都是在第一次开发的时候就埋藏下的。我们应该遵守开发规范，它为我们划定了一个范围，让我们不能越雷池一步。一个长代码的方法理解起来就很费力，重复代码以及写死的常量都有可能成为给后继者埋的雷。更深的层次，比如开发习惯与与众不同，使用了与本项目不同的代码架构（或者压根没有使用架构），这些往往会滋生出浅层的问题，从而给维护带来困难。
简明扼要是精髓。规范内容应尽可能简单明了，原因很简单，程序员不喜欢太繁琐且不实用的规范。
领会意图--自觉遵守的驱动力。强调遵守规范不如强调规范的意图。程序员应该了解规范制定的意图，并从中切实领悟到这样做带来的好处，意图就好比武功秘籍修练的心法，领悟不到其中的好处就不要奢望程序员能去自觉遵守。所谓不改初心，方能始终，对于一个成熟的程序员，规范的好处他会铭记于心，不必去强调要遵守规范，他自己会自然地遵守，因为他已经领悟到这样做的好处。
重构--有时是规范的二次执行。重构能够消除雷区，也不一定能确保不引用新的bug，对于一段需要不断维护的代码，重构是值得的。不断维护一个超长的方法，不如把这个方法重构成更加结构化的代码，比如若干意义明确的方法。最基础的重构有时候是规范的二次执行，高级的重构则伴随着程序员水平的不断提升。
代码不止是语言元素的简单组合。大家或多或少能了解遵守规范的好处，然而并不一定能够和愿意涉足重构，很多时候我们不去破解代码维护的困局，而是继续在这困局中挣扎，或许是不得已，或许是不愿意去触碰那可能的雷区，这就丢失了好多成长的好机会，每一次的重构都能促使我们反思：什么样的代码才是好代码？对于程序员来说，这个问题很有意义不是吗。