对于代码好坏的判断，是需要一定的标准来衡量。比如可读性，可维护性，可拓展性，简洁性等等，
好的代码，无论是对于代码开发者来说，还是对于设备维护者来说都是赏心悦目的，而坏的代码则是让人一头雾水，心生胆怯。甚至在开发和维护阶段，因为修改或者重构代码需要花费很多的时间，进而不愿意冒这个风险，最终会导致代码越来越烂，越来越拖沓。
下面就是好的代码，和坏的代码进行举例说明:
// bad
if (a === 'a') {
b = a
} else {
b = c
}
// good
b = a === 'a' ? a : c通过上面的示例可以看出，好的代码能给人愉悦的心情，坏的代码，虽然也可以实现对应的功能，但是不够优雅和从容。
1. 可读性:
可读性最直白的理解就是可以读，能否符合编码规范，是否可以见文知义，函数的长度是否合适，模块是否清晰，是否符合高内聚以及低耦合的特征。对于注释，这个见仁见智。我的理解是如果命名各方面都比较具体，函数的划分也比较合理，代码本身就是能够体现程序的意图，进而不需要注释。
2. 可维护性
可维护性，是指代码经得起维护，或者说便于维护。因为我们知道代码的维护成本占到开发成本的60%左右，维护这样大成本，除了软件功能复杂外，还有一部分原因是软件在设计之初，并没有考虑维护性的处理，文档是否完整和详尽，以及代码是否注重高内聚和低耦合的原则，这样设计的好处时，不至于出现问题后，修改问题，牵一发而动全身， 改一个问题，又引起其他潜在的问题。
3.可拓展性
这么多年来，我觉得switch是一个好的关键词，在增加新的判断条件时，并不需要修改原有的代码逻辑，只要在case之后，增加新的判断条件即可.当然也有一些开发模式也非常具有拓展性，比如工厂模式。这里涉及到开闭原则，
| “开闭原则，在面向对象编程领域中，规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。” |
4. 简洁性
简洁性，就是简单明了。在实现功能的同时，尽可能代码简单和清晰，一个函数只实现一个功能。
思从深而行从简。真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本质区别之一。下面的示例:
让我们看一个示例。如下图所示，从A至B，如何走。
