软件工程师，要么不写代码，要么就写优雅的代码-Toy模板网

这篇具有很好参考价值的文章主要介绍了软件工程师，要么不写代码，要么就写优雅的代码。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

何为优雅的代码

优雅的代码，至少需要遵循以下几个原则：

遵守规范

优雅的代码，首先让人看起来就是很整洁的。而这种整洁，则来源于代码规范。严格地遵守代码规范，是提高且保证代码质量的最有效方法。从个人开发的角度来看，一份良好的代码规范，能够对代码整洁起到指导帮助作用。从多人协作的角度来看，统一的代码规范能够有效减少沟通的阻碍。

逻辑清晰

代码是逻辑的产物。编写代码时，业务相关的逻辑一定要清晰明确，不能模棱两可。除此之外，对于所定义的变量、代码块、数据结构、方法、类、模块等，也要有逻辑地组织它们。

严谨可靠

严谨的代码，才能保证它的可靠性，减少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如何能做到在卡内基音乐厅演奏的时候，他的答案是：“练习，练习，再练习。”对于软件开发也是如此：阅读他人优雅的代码，编写代码，不断练习。但很多人忽略了第一步和第三步，总是在不停地编写代码。实际上，第一步和第三步更为重要，它反应了我们借鉴、学习和思考的过程。