软件工程师,要么不写代码,要么就写优雅的代码

软件工程师,要么不写代码,要么就写优雅的代码

首页角色扮演代号希望更新时间:2024-08-01
何为优雅的代码

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

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

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

严谨可靠:严谨的代码,才能保证它的可靠性,减少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真的不用处理吗?… …

总结推荐书籍

查看全文
大家还看了
也许喜欢
更多游戏

Copyright © 2024 妖气游戏网 www.17u1u.com All Rights Reserved