优雅的代码，至少需要遵循以下几个原则：
遵守规范：优雅的代码，首先让人看起来就是很整洁的。而这种整洁，则来源于代码规范。严格地遵守代码规范，是提高且保证代码质量的最有效方法。从个人开发的角度来看，一份良好的代码规范，能够对代码整洁起到指导帮助作用。从多人协作的角度来看，统一的代码规范能够有效减少沟通的阻碍。
逻辑清晰：代码是逻辑的产物。编写代码时，业务相关的逻辑一定要清晰明确，不能模棱两可。除此之外，对于所定义的变量、代码块、数据结构、方法、类、模块等，也要有逻辑地组织它们。
严谨可靠：严谨的代码，才能保证它的可靠性，减少bug的发生几率。一份代码即使严格遵守了代码规范，但思考不全面，逻辑不严谨，到处都是各种漏洞和bug，也不能称之为优雅。
为什么要写优雅的代码软件工程师有一大箩筐的借口来抵制提升代码质量的要求，更不用说还要编写优雅的代码了。想让我写优雅的代码，没门！
1、项目进度这么赶，bug这么多，改都改不完，哪有时间写好代码？
2、代码写得好不好无所谓，也无关紧要，能完成功能，并且不出什么bug就万事大吉了。 3、上一个人留下的代码就是那么烂，我能怎么办？我也没办法，好无奈啊。
4、代码写得再好有什么用？公司又不给加薪升职。
5、公司那么抠，加班那么严重，领导那么挫，还指望我好好写代码？
... ...
这里给出软件工程师必须写优雅的代码的几点理由。
1、代码首先是写给人看的，其次才是计算机能够运行。
能完成功能，也就是完成了开发任务，是应该的。但我们的项目是持续迭代的，以前写的代码以后还要去查看和修改，如果每次都只有完成功能的最低要求，日积月累，这个项目所能达到的质量也只会是最低要求，并且这个最低要求还会进一步降低。 另外，你所编写的代码，在你维护这个项目的期间，你是面对它最长时间的人。写得好，你看起来会舒服，心情也会更好；写得烂，恶心也只会恶心到你自己。
2、写好代码更能省时间。其实比起写低质量的代码，写出优雅的代码更能节省时间。 首先，优雅的代码是逻辑清晰的，简单直观的，所以在开发或维护的时候，读逻辑清晰的代码，自然要比读逻辑混乱的代码要更容易，由此就可以把更多的精力与时间花在功能开发上，而不是理清以前逻辑上。 其次，编写代码时，思维清晰，就可以写出更严谨的代码，这样就能减少bug，也就减少了修复bug所花费的时间。 不应该把时间都耗费在代码的修复上，而应该更多地用于创造性的工作上。而编写优雅的代码，正是达成这一目标的有效方法。
3、做一个有所追求的软件工程师，而不是一个得过且过的码农。
你的代码质量，应该取决于你自己，而不是你的公司、你的领导、产品经理、设计人员，或是项目以前的负责人。有追求的你，不应该让他们成为你降低自己要求的理由。你对自己有所追求，对代码也应当有所追求。
大牛们的话关于写优雅的代码这个话题，很多大牛们发表了自己的见解，一起来了解一下吧。
□ 最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。而构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。美的系统是灵活、易于理解的，构建、维护它们就是一种快乐。 —— 《敏捷软件开发》
□ 代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护和升级奠定了良好基础。 —— 《代码整洁之道》
□ 在代码阅读中说脏话的频率，是衡量代码质量的唯一标准。 —— Robert C. Martin，世界级编程大师，设计模式和敏捷开发先驱
□ 简洁的代码简单直接。简洁的代码如同优美的散文。简洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直接了当的控制语句。 —— Grady Booch，美国Rational软件工程公司的首席科学家
□ 我喜欢优雅和高效的代码。代码逻辑应该直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码。性能调制最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。 —— bjarne stroustrup，C 语言发明者
□ 我可以列出我留意到的简洁代码的所有优点，但其中有一条是根本性的。简洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地，代码作者几乎什么都想到了，如果你企图改进他，总会回到原点，赞叹某人留给你的代码 —— 全心投入的某人留给你的代码。 ——《修改代码的艺术》
□ 如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。 —— Ward Cunningham，wiki发明者
如何编写优雅的代码1、尽量消除硬编码。 什么是硬编码，就是说在代码里面，你用的一些变量是写死的。在代码中需要硬编码时，我们要想一想，这个硬编码的值在某些情况下会改变吗，为什么是这个值而不是其他值，确定需要这个硬编码的值吗，等等。当我们思考这些问题后，你会发现，绝大部分硬编码可以转换成常量、宏定义、程序配置等，或者根本不需要。
2、代码不是越短越好。 减少代码行数是一个好目标，但是减少阅读代码的时间是一个更好的目标。
assert((!(bucket = findBucket(key))) || !bucket.isOccupied());
上面的代码只有一行，看似很简洁，但不便于阅读，最好修改为如下代码。
bucket = findBucket(key);
if(bucket != null && !bucket.isOccupied())
3、注释不是越多越好。 （1）不要为那些从代码本身就能快速推断的事实写注释。注释一定是表达代码之外的东西，代码可以包含的内容，注释中尽量不要出现。比如，下面示例代码中的注释就是多余的。
class CStudent
{
public:
// Constructor
CStudent();
// Set the name member to a new value
void setName(const string &strName);
};
（2）不要给不好的名字写注释，而应该把名字改好。
// Releases the handle for this key.This doesn't modify the actual registry.
void deleteRegistry(RegistryKey key)
上面代码中的注释和函数名不是很匹配，应当从源头上修改函数名，而不是添加注释来费力地解释。
void releaseRegistryHandle(registryKey key);
（3）不要总想着用注释来解决看不懂代码的问题。如果你的代码不易理解，那就应该去改进它，让它能够“自解释”（把命名当做一种注释的方式，让它承载更多的信息），而不是依赖于大段的注释。
4、适当地注释。
（1）给重要的语句、解决的bug、关键的逻辑、疑难问题等添加注释。（2）给常量、宏定义添加注释。 （3）给代码中的瑕疵添加注释。 （4）站在读者的角度写注释。请注释意图（why），而不要注释实现（how)，大家都会看代码。
5、根据逻辑组织代码。 （1）声明成员变量的时候，通常应当把某个种类，或者某个功能点相关的声明放在一起，并且不同种类或功能点的声明之间应当留有空行。 （2）声明方法的时候，应当把相关联的方法放在一起，并用空行隔开，而不是按名字排序，或者从上到下一直堆砌。比如：定义了A(), B(), C()三个方法，其中A()调用了C()，那就应该把C()放在A()之下，而把B()放在这两个方法的上面或下面，而不是中间。 （3）在方法的内部，应当根据具体的业务用空行隔开不同的逻辑，这样不但使代码显得有段落感，也有助于对代码的整体理解。 （4）在定义类时，相关联的类应互相靠近。同一个库/包里的类应该是共同完成某个模块或功能的，即库/包内的代码应是高内聚的。
6、命名的原则：正确、准确、直观、简洁。 （1）正确是指：变量名能够表现它的属性，方法名能够表现它的行为，类名能够表现它的职责，库名/包名能够表现它的功能。 （2）在做到正确的前提下，再去追求准确。准确是指它的名字是正确并精确的，比如：用手机号是否为空去判断一个用户是否绑定了手机号，方法名isPhoneBounded()就要比isPhoneNotEmpty()要贴切些，尽管它里面的实现是判断手机号是否为空。 （3）直观是排在简洁前面的，名字长点没关系，只要直观就可以。 （4）在同样直观的前提下，如果有更简洁的命名，再选用更简洁的命名。命名可以使用缩写，但应该是大家约定俗成的缩写。比如：把message缩写成msg是可以接受的，但把notification缩写为noti或notif，是不太恰当的。
7、不要把所有变量都定义在开头。
（1）把所有变量定义在开头是C语言的风格，面向对象语言习惯将变量定义在它开始使用的地方。也就是，什么时候开始使用，什么时候定义。 （2）用到的时候再定义，既可以缩小变量的作用域，也更符合人的逻辑思维习惯。
8、提高代码可读性。
（1）通过提前返回减少嵌套。
if (a) {
if (b) {
if (c) {
// ...
return true;
}
}
}
嵌套太多，不利于阅读和理解，可以修改为如下方式。
if (!a) {
return false;
}
if (!b) {
return false;
}
if (!c) {
return false;
}
// ...
return true;
（2）适当地总结变量。
if (A == B) {
}
if (A != B) {
}
对A == B表达式进行总结，便于后面复用。
bool bRet = A == B;
if (bRet ) {
}
if (!bRet ) {
}
（3）减少控制流里使用的变量。
boolean done = false;
while (/* condition */ && !done) {
if (...) {
done = true;
continue;
}
}
事实上，上面的代码可以不用done变量。
while (/* condition */) {
if (...) {
break;
}
}
9、提高代码可维护性。
（1）有互斥锁时，或者有资源创建时，除了对入参的检查可以直接return外，其他地方尽量不要中途return，只在方法的最后进行return。
mutex.lock();
if (!A) {
mutex.unlock();
return -1;
}
if (!B) {
mutex.unlock();
return -2;
}
mutex.unlock();
return 0;
上面的代码，在每个中途都可能return，此时需要记得释放互斥锁，很容易漏掉，从而导致程序异常。更好的方法是封装自动释放锁的辅助类，或者修改程序结构，不要中途return。
（2）代码中有多个资源需要动态创建和释放时，可采用do while结构，既便于理解，也不易引入错误。
char *pBuf1 = NULL;
if (A) {
pBuf1 = new char[256];
}
if (B) {
delete[] pBuf1;
return -1;
}
char *pBuf2 = NULL;
if (C) {
pBuf2 = new char[1024];
}
if (D) {
delete[] pBuf1;
delete[] pBuf2;
return -2;
}
// ...
delete[] pBuf1;
delete[] pBuf2;
return 0;
上述代码，在每个return的地方，都需要记得释放内存，不利于后期维护，很容易犯错。改为下面的do while结构后，代码变得更为简洁，也更易于维护了。
int nRet = 0;
char *pBuf1 = NULL;
char *pBuf2 = NULL;
do
{
if (A) {
pBuf1 = new char[256];
}
if (B) {
nRet = -1;
break;
}
if (C) {
pBuf2 = new char[1024];
}
if (D) {
nRet = -2;
break;
}
} while (false);
// ...
delete[] pBuf1;
delete[] pBuf2;
return nRet;
10、一个函数只做一件事。
（1）编写函数时，记住两条规则。第一条规则是要短小，第二条规则是还要更短小。 （2）更短小的函数，更易于阅读和理解。如果一个函数的代码过多，很可能是由于你没有对这个函数的功能进行深入思考和进一步分解。函数越大，滋生bug的几率越大，后期维护的成本也越大。
11、封装。 （1）时时刻刻将封装牢记在心：将不需要使用者知晓的细节全部隐藏起来，只暴露最少的接口给使用者。 （2）在各个不同的维度和层次使用封装，设计函数、类、包、库、模块、系统、架构时，都要仔细考虑如何进行封装。 （3）封装良好的代码，一定是高内聚、低耦合的，便于理解、扩展和维护。
12、全面思考。 （1）对一个问题思考得越全面，编写出的代码就会越严谨。 （2）多反问自己：这个接口被调用多次怎么办？这个接口不被调用，其他地方会崩溃吗？多线程使用这个接口会有问题吗？为什么这里要加锁，那里又不加锁？写了if，没写else，但else真的不用处理吗？… …
总结- 平均来说，一次编写的代码会被阅读十次，所以尽力保持代码优雅是有意义的。当养成习惯之后，你会发现基本不需要花什么力气，更优雅、更具维护性的代码很快就会产生收益。
- 优雅的代码有助于理解开发语言、模式和架构，也有利于提升开发水平。
- 史蒂芬·金在《关于写作》中说，想要成为优秀的作家需要大量的阅读和大量的写作。当人们问Henny Youngman如何能做到在卡内基音乐厅演奏的时候，他的答案是：“练习，练习，再练习。”对于软件开发也是如此：阅读他人优雅的代码，编写代码，不断练习。但很多人忽略了第一步和第三步，总是在不停地编写代码。实际上，第一步和第三步更为重要，它反应了我们借鉴、学习和思考的过程。
- 墨菲定律中有一条：凡是你认为可能会出错的，它一定会出错。这条定律在软件开发中非常常见，所以写代码时一定要严谨，而不是想着先把功能加好，后面再慢慢去优化重构。记住勒布朗法则：Later equals never（稍后等于永不）。
- 编写代码，如同写一篇文章。文章的段落划分，如同代码的架构组织。文章的标点符号，如同代码中的空格、空行。文章的措辞修饰，如同代码中的命名。文章的主线情节，如同代码的封装。好的文章，段落划分、标点符号、措辞修饰、主线情节，每一样都是精雕细琢。优雅的代码，亦是如此。
