图灵社区按
TEAP是什么?TEAP是Turingbook Early Access Program的简称,即早期试读,它公布的是图灵在途新书未经编辑的内容。一本书的翻译周期约为3到6个月,如果在翻译过程中,译者就能与读者进行沟通和交流,对整本书的翻译品质是有帮助的。通过TEAP,读者可以提前阅读将来才能出版的内容,译者也能收获宝贵的反馈意见,改进翻译,提高质量。

本书原名为Expert PLSQL Practices,中文暂定名为《Oracle PL/SQL实战》,本篇选自第12章 编码规范和错误处理)

我的博客

在同一时间,你能穿一身燕尾服和一双勃肯鞋吗?是的,你能!每个在粒子物理实验室度过了一段时间的人都知道它在技术上是可行的。然而,有些人可能会说,这样装备的与优雅的惯例冲突。你可能还喜欢穿绿色和蓝色服装的组合。(我个人比较喜欢红色和黑色混合)。对我们各自的口味,我们可以争辩不休:每个人都是正确的,每个人也都是错误的。同时,书面或书面的规范也对我们的生活和工作带来帮助。他们各有自己的历史和理由。

写代码往往是充满乐趣的,我们都希望把它写得尽可能的好:在执行效率,结构紧凑等方面,如果可能的话,还包括编码风格。但我们不只是为自己写代码。如果你曾经阅读别人写的一段代码,以详细了解它是做什么的或调试或修改它,你可能想:“嗯,我不会用这种方式做。”它可以工作但它可能难以理解,有点像听一个带有浓重口音的表弟说话。本章的目的是要提出一种编写PL/SQL的方法。我将首先讨论编码规范的好处,然后提出具体的格式规范。然后,我将讨论错误处理并提供错误处理的规范的例子。在本章结束处,我用一个模板总结了本章所述的规范。

■ 注意:我绝对不假装我刚才概述的规范是唯一可行的,但这些规范已经在我的日常工作中证明了他们的效率/有效性。我认为,重要的是要了解各种规范的原因,并看到一个方法相比另一个方法具有什么好处。

为什么要制定编码规范?

既然很麻烦为什么还要(用?)它?我们真的需要编码规范吗?让每个人充分施展自己的艺术才华,允许大家自由支配变量命名,缩进循环,以及更多的东西岂不是更好的吗?这种自由可能听起来很诱人,但它是通向毁灭/破坏的道路,或者至少不是一条按时回家用餐的道路,因为你要停留在办公室调试一些高深莫测的代码。以下是创建整体结构和坚持一套良好的规则产生的一些好处:

快速的理解:遵从规范编写的代码比较容易读,因此它读起来更快。只是需要一点点实践,读者的眼睛立即就能识别出代码中的模式。如果结构看上去清晰,那么各类元素和逻辑块就会变得很明显。它也有使误解的可能性最小化的好处。说“我喜欢吃巧克力”比说“我不否认我不讨厌巧克力”是更好的,尽管这两个句子的意思是同样的。

可靠性:一旦你的代码编写完成,最好把它交给同事审查,以寻找可能的错误和不一致,并确保其逻辑是明确的。容易阅读且容易理解的代码有助于一个更好的检查,然后它可能是更可靠的。以我的经验,我知道这也使得更容易找到审阅人对我的工作进行检查,因为他或她知道,阅读我的代码将不会是一个痛苦的过程,这种痛苦来自于我扭曲/变态的风格表达。

可维护性:随着时间的推移,维护代码是一个挑战。甚至当你几个月后重新审视自己的代码时,你都可能会发现它很难理解。当整个包是由几个人合作编写的时,情况会变得更糟。确保在系统的生命周期中使用一个共同的风格对它的维护有很大的帮助。

安全性:编码规范可以提高系统的安全水平。例如,系统使用绑定变量可以隔绝代码注入威胁。这方面更详细的描述,参见下面的段落。

可训练性:当几乎每年都会改变负责系统的团队中的一半成员时,关键是要尽快培养每一个新人。如果每个人都用同样的方式说话,那么训练速度就会更快。有可能发生一个新人不愿意学习用一种新途径来使用他或她已经掌握的一门语言的情况。要敢于对整个团队强制执行标准,如果可能的话,让新人在现有的模块上工作。发现到处是相同的编码风格,将很快作为一个优势出现。

编码的速度:为什么每次启动一个新的模块编码时要推倒重来?使用编码规范,你可能会减少几个问自己关于你的代码风格的问题。例如,修改现有的程序时,你应该遵从原作者的风格还是应该使用你自己的风格?当每个人都使用相同的风格时,这样的困境简单地消失了。

错误处理:确保所有的错误都被优雅地捕获和正确地处理是提供良好的软件的另一个棘手的问题。因此,重要的是有一个系统化的方法来处理错误且用标准化的方式报告错误。编码规范可以在软件编程的这方面带来强大的解决方案。