虽然这样的文章非常的多，并且，就算是对于编程新手来说，也是非常的简单和显而见，但是，在我们进行Code Review过程中，我们还是能够看到那些非常混乱的代码，所以，有些时候，你会在想，是不是这样的规则太多了，导致我们的程序员记不住。虽然我们在以前的文章中一遍又一遍的说过（比如：《优质代码的十诫》），千言万语总结一下，无论你用什么样的语言，最最基本的编程原则就是下面这四条。
1 – 简短的方法
简单才会易读，简单才会容易，简单才能重用，简单才能保证质量。把一件事搞复杂，是一件简单的事；而把一件事变简单，这则是一件复杂的事。KISS-Keep it Simple Stupid是一种哲学，Do one thing, Do it best也是一种哲学。这些都是在告诉我们，做设计，做产品，不要把所有的东西一下子都考虑进来，否则将会让你的事情变成一团糟，剪不断理还乱，就是这样道理。把复杂的事情，困难的事情，逐步细化，分解成一个一个简单而单一的事情，然后再把他们拼装起来完成一个复杂的事情，是我们如何完成一个巨大并复杂的项目的通用方法。
编程也是这个道理，维护代码的成本会比你创造代码的成本要大得多，所以，一个简短的方法不但可以有利于阅读，维护，重用，同样在进行排错调试测试的时候也能起到巨大的帮助。比如，对于一个简单的方法或函数，单元测试，功能测试，性能测试、代码覆盖，质量保证都能变得相当简单，而这些众多的质量优良的方法最终组成了那质量过硬的最终产品，并让我们在以后的代码不断改进中继续充当重要的作用。
2 – 选择望文知意的直观的变量名和函数名
无论是变量名还是方法名，都不能太长或是太短。一个好的命名，应该是“自解释的”，直观的，望文知意的。通常来说，一个好的命名应该是知道这个变量/方法要干什么事情，比如GetComputerName()，isAdmin等等，对于变量名来说，通过其名字，我们可以知道这个变量的类型（整型，浮点，指针，……），种类（全局，成员，局部，静态，……）。关于命名的事情，可以查看《编程命名中的7+1个提示》和《编程中的命名设计那点事》查看更多的内容。
3 – 只写有意义的注释
代码写得好的话，是不需要注释的。与其花费大量的时候去写注释，还不如把这些时间花在代码重构上，简洁/易读的代码比详细的注释更有意义。另外，如果你需要使用你的注释来生成文档，那么也不需要太过复杂，这通常用来做API的文档，这个时候，关键不在于你是如何实现的，而是在于告诉别人完成什么样的事并如何使用之。总之，一句话，如果你的代码足够的简单和清楚，你是不需要写注释的。
4 – 让你的代码可读
你的代码并不只是让编译器去阅读的，你的代码更应该是让你的同事和其它人阅读的。所以，一定要遵守团队内部的那些最中规中矩的编程规范或代码风格，千万不要在代码中使你的小聪明或是偷懒或是hack代码，那样做的结果只会有两个，一个是你的代码会被后人骂得一无是处，另一个就是当你在以后维护你的代码时无异于搬起石头砸了自己的脚。编码坚持最基本的两个原则—— KISS 和DRY，剩下的就是顺从于自然。