自描述
命名恰当规范，看名字就知道意思。包括包、类、方法、变量等等，而不是靠注释去理解。当你需要注释才能描述清楚你想干嘛，请思考一下，能否从命名就说清楚？除非是在不行，否则不要依赖注释。
注释的一个坏处是，你不能保证注释和代码是同步的。当你由于某些原因改了代码，而没有修改注释，这时候注释是误导人的，还不如没有。
注释会带来代码的噪音。遍布代码里的注释，让你无法抓住代码要点，而是要费劲去阅读注释。
简单
简单容易理解的代码就是短的代码。有有限的行数（方法低于10行是个不错的标准，低于7行是个更好的标准，再低可能不容易做到），较少的缩进层次（两层以内，最多不高于3层）。
过长的方法可能是因为你违反了单一职责原则。试着对方法进行重构，对方法里的代码进行分层。每个方法只干一件事儿，减少代码的行数。
过大的类也是一种复杂。试着重构，将类的职责分离出来，保持类的单一职责。对于复杂逻辑，尝试用常用设计模式，如类工厂等方法将一些逻辑分布到其他类中。
容易修改
当你把相同原因相同时间变化的放到一起，不同原因不同时间变化的分开，代码就容易修改。从纵向上，把UI、业务逻辑、数据库访问等分开，高层的业务逻辑和底层的UI数据库解耦；从横向上，不同的UseCase分开为不同的模块。这样代码会更容易修改。
面向对象赋予我们的利器：多态。进而实现依赖反转。从而让各个层次可以很方便用抽象解耦，一个层内部的修改，不会影响到其他层。
Open-Close原则，面向扩展开放，面向修改关闭。在增加新功能的时候，不需要或者极少需要修改原来代码。这样才能避免引入新的Bug。
容易测试
依赖简单的、职责单一的代码就容易测试。轻易Mock少数接口（甚至不需要），就可以完成对业务逻辑的单元测试。当你发现你的代码很难测试，极有可能是你代码做了太多的事儿，或者没有好好隐藏内部实现，导致调用者非常复杂。
如果你的对外依赖不容易通过Mock替代进行测试，说明你的代码违反了里氏替换原则。重新设计其他依赖，用接口进行隔离。
高效的
采用恰当的方法，是系统能够高效运行。比如不必要的打包解包、无谓的循环、频繁的锁竞争。当然对效率的优化首先要考虑代码前面几个原则，除非非常必要，不要以牺牲可读性、可测试等特性为代价。