Oracle数据库PLSQL编码规则总结

我从1990年开始写PL/SQL代码。这意味着我写了几万行软件代码，但我肯定大部分都很差，很难维护。

幸运的是，我发现寻找并遵循新的方法来编写更好的代码还为时不晚。就在去年，我的代码质量显著提高；这些改进主要是由于制定了一些简单的规则，并像遵守纪律一样遵守这些规则。

本文对PL/SQL新手和有经验的开发者提出四点建议。遵从其中的任何一条，你的代码质量都会得到提升。四个建议全部采纳，你可能会惊讶地突然发现，你是一个非常优秀的程序员，远远超出你的想象。

所有的工作都是独自完成的。

我们很少有人独自工作；大多数PL/SQL开发工作是在相对较大的机构中进行的。但是我们基本上是在自己的隔间里用自己的设备独自工作。很少有PL/SQL开发团队进行正式的代码审查或系统测试。

我无法通过这篇文章改变你开发团队的基本状态。因此，我精心挑选了以下建议。以上任何一点的实施都不需要管理者的同意。无论你的团队是大是小，没有必要让每个人都同意这些编码规则。您只需遵循以下建议来更改您自己的编码方法:

1.严格遵循命名惯例，仿佛它们是你生命的脊梁。
2。戒掉写SQL的爱好:SQL写得越少越好。
3。让执行部分简短些:告别“意大利面条代码”。
4。找个搭档:我非常同意找个人来监督你的工作。
1。遵循命名约定。

如果您建立并严格遵循一组命名约定，尤其是对于应用程序组件，您可以节省大量时间。

当然，遵循命名约定的想法并不新鲜，您可能已经听腻了。所以我不提出什么宏大的命名方案，而是给出一些非常具体明确的约定，然后证明这些约定会有多大用处。

在过去的几个月里，我一直在为PL/SQL开发人员设计和构建一个新工具。它叫Swyg(可以在www.swyg.com找到)，它可以帮助程序员完成代码的生成、测试和重用。它有几个独特的组成部分。我为每个组件指定了两个字母的缩写名称，如下所示:

SF-Swyg的基本组件
SM-Swyg的元数据
SG-Swyg的生成器
SL-Swyg的代码库
ST-Swyg的单元测试
所以我遵循了表1中的命名约定，同时使用了这些缩写。遵循这些惯例有什么好处？一般来说，如果我要求一致的命名规则，我可以更流畅、更高效地编写代码。

具体来说，这些约定是可预测的，这意味着我编写的SQL程序可以生成有用的脚本。例如，通过使用表1中的约定，您可以为Swyg中的所有基本包生成安装脚本。执行这些任务的SQL*Plus脚本如清单1所示。这种脚本非常有用，因为这意味着我不必手动维护安装脚本。当我在Swyg scheme中再添加一个表，生成一组相关的包，我只需要运行我的脚本，更新后的安装脚本就会跳出来。2.戒掉写SQL的爱好。

SQL写得越少越好，这似乎与我们的直觉不符。对于PL/SQL开发人员来说，这是一个奇怪的建议，因为PL/SQL的主要优点之一是可以毫不费力地用代码编写SQL语句。然而，这种简单性也是这种语言的致命弱点。

纯SQL语句可以直接放在PL/SQL代码中，无需JDBC或ODBC等中间层。因此，无论何时何地，PL/SQL开发人员需要SQL语句时，通常会将它们嵌入到应用程序代码中。那么这有什么问题呢？

在PL/SQL代码中处处使用SQL语句将不可避免地导致以下后果:

虽然实际性能有所不同，但是同样的逻辑语句还是会重复，导致解析太多，很难优化应用的性能。

公开业务规则和程序。这直接包含了在SQL语句中执行业务规则的逻辑。这些规则总是在变化的，所以应用程序的维护成本会急剧增加。

当然，几乎所有要编写的PL/SQL应用程序都基于基本的表和视图。您需要执行SQL语句。问题不是要不要执行，而是什么时候执行，怎么执行。

如果您封装数据结构或将它们隐藏在PL/SQL代码层(通常是一个代码包)之后，那么您的应用程序将更加健壮，并且您会发现创建和维护它要容易得多。

让我们看一个简单的例子。假设我需要写一个程序来处理一个员工的工作。第一件事是获取员工的全名，定义为“姓名逗号(，)姓氏”；然后我就可以详细分析了。清单2给出了我可能在这种情况下编写的这种代码的例子。

一切都显得那么简单直接；这些代码会有什么问题？其实真的很糟糕。最重要的是我暴露了一个业务规则:全名的结构。我可能要花几个小时来测试这段代码和它所基于的应用程序。但就在投入使用的时候，我意识到客户会不断打电话告诉我，其实他们的全名应该表示为“名字空 case姓氏”。

现在怎么办？搜索引号内的所有单逗号？

现实的解决方案是使用一个包，它隐藏了所有细节，只提供一组预定义、预测试和预优化的包，并且可以完成所有任务。清单3展示了基于封装代码重写的process_employee流程。hr_employee_tp包提供了用于定义名称的局部变量的类型；Hr_employee_rp包含一个基于业务规则返回全名的函数。

将PL/SQL语句注入SQL代码很容易。同样，谈论封装这些语句有多重要也很容易。另一方面，编写执行封装任务的代码是一项挑战。甚至不现实。生成这些包可能更有意义。

几年前，我帮助建造了这样一台发电机。这个程序段就是PL/Generator，现在归Quest Software所有，PL/SQL开发社区可以免费使用。你可以从我的网站www.StevenFeuerstein.com/puter/gencentral.htm.下载，你知道，它的包装结构与我之前概述的惯例不同。PL/Generator创建一个单独的包，其中包含表的类型、查询和更改逻辑的所有内容。

当你不再写太多的SQL，而是调用执行SQL的程序时，无论是生成还是编写自己的自定义包，你的应用都会受益匪浅。
3。操作部分要简短。

让我们面对它:总是与我们的判断和最新的一系列新年决心相反，我们必须停止编写意大利面条式的代码:它们庞大而冗长，人们几乎不可能理解它们，更不用说维护或升级它们了。怎样才能避免“意大利面”？

其实答案很简单:绝不允许执行部分超过50或60行。这个大小使你能够在一个页面或者一个屏幕上查看代码块的整个逻辑结构，也意味着你能够真正理解程序的意图，完全直观地理解它。

你可能很赞同上面的观点，但同时又嘲笑我的建议:程序代码永远不要超过50行。是的，你应该嘲笑它，因为它当然是不可能的。毫无疑问，你需要50行以上的可执行代码；问题是你把这些代码放在哪里，如何组织它们。

如果你采取以下措施，你真的可以处理各种复杂的需求，把代码限制在50行以内:

将所有业务规则和离散的逻辑块放在它们自己的程序(通常是函数)中，以便尽可能地重用代码。

尽量使用程序声明部分定义的局部模块、过程和函数。

假设我正在编写一个呼叫中心应用程序。我需要编写一个满足以下要求的程序:

“对于特定部门的每个员工，将他的工作量(分配给该员工的呼叫数)与该部门员工的平均工作量进行比较。如果一个员工的工作量低于平均工作量，那么下一个未接电话将分配给这个人，并根据这种情况安排预约。”

我从之前的工作中了解到，我的朋友Claudia已经编写了一个分析包，它将返回关于工作量的信息。然而，分派未决呼叫和安排约会都是新的任务，在需求文档的其余部分会有详细描述。

最初，我想读完这15页，但我没有这样做。我使用了一种称为“逐步细化”或“自顶向下设计”的技术，首先编写清单4中的代码来实现程序。

清单4中最关键的代码行解释如下:从程序的最后一部分(紧凑执行部分)开始，逐步进行。这看起来是反直觉的，但这确实是一步一步细化方法编写的通读程序的方法。

第22到30行。使用游标FOR循环迭代处理指定部门中的所有雇员。在第24 ~ 25行，使用分析包中的程序来确定当前雇员是否工作不足。在第27到28行，调用了三个程序:assign_next_open_case、schedule_case和next_appointment。我还不知道这些程序是如何实现的，但我知道它们通过名字和参数表表达了需要提前做的工作。

第10 ~ 19行。为第27 ~ 28行中的三个程序创建“存根”，这是占位符程序。注意，它们是本地模块，在assign_workload中定义，不能从任何其他程序调用。

第5到第8行。定义一个游标来获取指定部门的所有雇员。现在，您可以尝试编译这段代码。

成功编译了这么一个小程序，看似小胜，实则如此。完成正确的编译，然后简单测试，再加一点代码，然后编译正确，以此类推。这样的小胜利创造出构造良好的程序，他们会非常满意。

我还可以验证分析程序是有效的，并找出合适的员工来完成分配的任务。这些工作全部完成后，我会在assign_next_open_case等三个程序中挑出一个，进行下一步或下一层次的精细设计。我想看这个任务的文档，在assign_next_open_case里面写一个简短的执行部分，可以反映这个任务的大概情况。

很快，我的本地过程有了自己的本地过程和函数，但是在过程的每一步，我的代码都很短、易读、易于测试，并且可以根据需要进行调整。
4。找一个好的伴侣。

电脑不会编程，人会。

有多少次你在电脑前弯腰驼背，因为找不到代码中的错误而感到非常沮丧？先是几分钟过去了，然后几个小时过去了。最后，你厌倦了自己，感觉很失败，你从你的隔间里伸出头，叫你的朋友来看你。

通常有以下三种情况之一:

当你的朋友从椅子上站起来的时候，一切都在一瞬间变得非常清晰。

你的朋友看了一眼屏幕，立即指出了问题所在。

你的朋友不负责你在系统中做什么，所以你必须解释你的程序在做什么。当你一步步解释逻辑的时候，导致错误的问题就会突然暴露在你面前。

其实调试自己的代码很难，因为你太投入太专注了。

解决这个问题的方法是由开发经理创造一种文化:各种想法被分享，无知可以被原谅而不会被惩罚，建设性的代码评审可以定期进行。不幸的是，这些文化变革很难实现。

同时，我建议你应该带头帮助改变你所在小组的文化。找另一个比你更有经验的开发者，建立“伙伴”关系:出现问题时他可以充当你的顾问，当然你也可以充当他的顾问。事先达成共识:不知道所有问题的答案并没有错。

然后给自己定一个简单的规则:不要在一个错误上纠结超过半个小时。30分钟过去了，打电话给你的伴侣，让人类的心理为你服务，而不是和你作对。

获得新工作方式的四个步骤

本文为您提供了四个步骤来改变您的编程体验，而无需投资新工具或改变整个团队的工作流程。你甚至不需要遵循所有的四个步骤，只要遵循一个步骤，你就会受益。