价值观
沟通：如果阅读者可以理解某段代码，并且进一步修改或使用它，那么这段代码的沟通效果就很好。在编程时，我们很容易从计算机的角度进行思考。但只有一面编程一面考虑其他人的感受，我们才能编写出好的代码。在这种前提下编写出的代码晚加干净易读，更有效率，更清晰地展现出我们的想法。
在编程时注重沟通还有一个很明显的经济学的基础。软件的绝大部分成本都是在第一次部署以后才产生的。从我们修改代码的经验出发，我们花在阅读既有代码上的时间要比编写全新的代码长得多。如果我们想减少代码所带来的开销。我们就应该让他容易读懂。
注重沟通还可以帮助我们改进思想，让它更加现实。一方面是由于投入更多的思考，考虑“如果别人看到这段代码会怎么想”所需要调动的脑细胞，和只关注自己是不一样的。
简单：存在于旁观者的眼中。一个可以将专业工具使用得得心应手的高级程序员，他所认为的简单事情对于一个初学者来说可能会比登天还难。只有把读者放在心里，你才可以写出动人的散文。同样，只有把读者放在心里，你才可能编写出优美的程序。给阅读者一点挑战没有关系，但过多的复杂性会让你失去他们。在复杂与简单的波动中，计算机技术不断向前推进。直到微型计算机出现之前，大型机架构的发展倾向仍然是越来越复杂。微型计算机并没有解决大型机的所有问题，只不过在很多应用中，那些问题已经变得不再重要。编写语言也在复杂和简单的起伏中前行。C++在C的基础上产生，而后在C++的基础上又出现了JAVA，现在JAVA本身也变更越来越复杂了。
灵活：灵活性是衡量那些低效编码与设计实践的一把标尺。灵活性的提高可能以复杂性的提高为代价，比如说，给用户提供一个可自定义配置的选择提高了灵活性，但是由于增加了一个配置文件，编程时也需要考虑到这一点，所以也就复杂了。反过来简单也可以促进灵活。如果可以找到取消配置选项但又不丧失价值的方式，那么这个程序以后就更容易改动。总之，程序是该灵活，但只有在发生变化的时候才需要如此。
原则
局部化影响：组织代码结构时，要保证变化只会产生局部化影响。如果这里的一个变化会引出那里的一个问题，那么变化的代价就会急剧上升了。把影响范围缩到最小，代码就会有极佳的沟通效果。它可能被逐步深入理解，不必一开始就要鸟瞰全景。
最小化重复：如果相同的代码出现在很多地方，那么改动其中一处副本时，就不得不考虑是否需要修改其他副本。变动不再只发生在局部。代码复制越多，变化的代价就越大。我们可以把程序拆分成许多更小的部分--小段语句、小段方法、小型对象和小型包，从而消除重复。
将逻辑与数据捆绑：局部化影响的必然结果是将逻辑与数据捆绑。把逻辑与逻辑所处理的数据放在一起，如果有可能尽量放到一个方法中，或者退一步，放到一个对象里面，最起码也要放到一个包下面。在发生变化时，逻辑和数据很可能会同时被改动。如果它们被放在一起，那么修改它们所造成的影响就会只停留在局部。
对称性：程序中处处充满了对称性。比如Add()方法总会伴随着Remove()方法，一组方法会接受同样的参数，一个对象中所有的字段都具有相同的生命周期。识别出对称性，把它清晰地表述出来，代码将更容易阅读。
变化率：把具有相同的变化率的逻辑、数据放在一起，把具有不同变化率的逻辑、数据分离。变化率具有时间上的对称性。有时候可以将变化率原则应用于人的变化 。例如，如果开发一套税务软件，我们会把计算机通用税金的代码和计算机某年特定税金的代码分离开。两类代码的变化率是不同的。在下一年中做调整的时候，我们希望能够确保上一年中的代码依然奏效。分离两类代码可以让我们更确信每年的修改只会产生局部化影响。