关于程序设计语言（PDL）

关于程序设计语言（PDL）
使用原则
1。用日常语言来精准描述每一个特定操作
2。避免使用程序语言。
3。要说明方法的意义，不是描述如何使用或方法的流程。（描述清楚为什么有这个方法）
4。不能写的太简略，会忽略问题细节。

eg:
         Keep track of current number of resource in use
         If another resource is available
                Allocate a dialog box structure
                If a dialog box structure could be allocated
                        Note that one more resource is in use
                        Initialize the resource
                        Store the resource number at the location provided by the caller
                Endif
         Endif
         Reture TRUE if a new resource was created; else return FALSE

    PDL的优点：
    1。可以使评审工作变得更加容易
    2。可以帮助实现逐步细化的思想
    3。使变动工作变得很容易
    4。减少了注释工作量
    5。比其他形式的设计文件更容易维护

    创建方法的准备工作：
    1。定义要解决的问题
    2。方法命名(如果名字模棱两可，那么结构设计就可能出问题)
    3。决定如何测试程序
    4。研究最近的算法
    5。编写详细的PDL
    6。考虑效率
    7。考虑数据
    8。重新检查PDL的数据

 

 

关于开发心理的一点建议：自己用心理检查完代码后才进行第一次编译，因为一旦开始编译， 那么你脑袋里的秒表便开始嘀嗒作响了，在第一次编译之后，你就开始不停地想：下次编译一 定让它全对。结果，在这种“就只再编译一次”的压力下，作了许多匆忙的、更易产生错误的 修改，反而浪费了更多的时间。所以，在确信子程序是正确的之前，不要急于开始编译。

 

创建子程序
· 是否检查过先决条件已经满足了？
· 定义子程序将要解决的问题了吗？
· 结构设计是否足够清楚，使得你可以给子程序起个好名字？
· 考虑过如何测试子程序了吗？
· 是否从模块化水平或者满足时间和内存需求角度考虑过效率问题？
· 是否查阅过参考书；以寻找有帮助的算法？
· 是否用详尽的 PDL 设计子程序？
· 在必要时，是否在逻辑设计步骤前考虑了数据？
· 是否检查过 PDL，它很容易理解吗？
· 是否注意到了足以使你返回到结构设计阶段的警告（使用了全局数据，更适合其它子 程序的操作，等等）。
· 是否使用了 PDL 到代码流程，是否把 PDL 作为编码基础并把原有的 PDL 转为注释？
· 是否精确地把 PDL 翻译成了代码？
· 在作出假设时，验证它们了吗？
· 是从几个设计方案中选择了最好的，还是随意选择了一个方案？
· 是否彻底理解你的代码？它容易理解吗？