子程序设计原则

子程序（routines）是为实现一个特定功能而编写的一个可被调用的方法（method）、函数（function）或过程（procedure）。如Java中的方法，C++里的函数。现代编程语言，如Java、C++、VB、JavaScript、Ruby等都同时支持函数和过程。

一般认为函数指具有返回值的子程序，过程指没有返回值的子程序。C++中把所有子程序成为函数，其实那些返回值为void的函数在语义上也是过程。函数与过程的区别更多是语义上的区别，而不是语法的区别。语言纯化论者认为，一个函数应该只有一个返回值，这和数学函数一样。即函数只接受输入（参数），通过参数运算返回结果。

以JS示例

?





1

2

3

4

5

6

function
sum1(x, y) {

    return
x+y   

}

function
sum2(x, y) {

    alert(x+y)   

}

sum1是一个函数，它有输入并返回结果；sum2则是过程，接受输入，处理输入（打印输出结果），但没有返回结果。

好的子程序需要遵循以下原则

  • 高内聚

  • 好的命名

  • 长度适中

  • 合理的参数

一、高内聚性


内聚性是计算机科学里很重要的一个概念，由Larry
Konstantin在1974年的一篇论文提出。它由分为以下

1. 功能内聚（Functional cohesion，最高）

最好最强的一种内聚性，即一个子程序仅执行一个操作，有的书也称“只做一件事，做好一件事”。这种子程序执行的操作与其名称多数是相符的，如sum执行相加，deletePage删除页面。

2. 顺序上的内聚（Sequential cohesion）

指子程序内需按特定顺序执行操作，这些步骤需要共享数据，且在全部执行后才完成子程序的完整功能。比如需要先计算A，再使用A计算B，接着取B计算C。

3. 通信上的内聚（Communicational cohesion）

是指子程序不同操作使用了相同数据，但不存在任何联系。

4. 临时的内聚性（Temporal cohesion）

是指含有一些因为需要同时执行才放到一起的操作的子程序。

5. 逻辑上的内聚性（Logical cohesion）

是指若干操作被放入同一个程序中，通过传入的控制标志选择执行其中的一项操作。

6. 偶热的内聚性（Coincidental cohesion 最低）

指子程序中各个操作直接没有可以看到的内联，也称为“无内聚性”或“混乱的内聚性”。

二、好的命名


好的命名能清晰的描述子程序所做的一切。以下是一些命名注意事项

1. 描述子程序所完成的功能

2. 避免使用无意义的、模拟或表达不清的词

3. 不要仅通过数字来区分不同的子程序名

4. 根据需要确定子程序名字的长度

5. 对返回值要有所描述

6. 一般是动词+名词形式

7. 使用对仗词，如add/remove, begin/end, first/last, get/put, up/down/, show/hide,
open/close。

三、长度适中


“子程序/函数的第一要素就是短小，第二条规则还是短小”，鲍勃大叔如此说。理论上认为子程序的长度最大长度通常是一屏代码，大约50-150行。

一项对子程序的研究发现，平均100-150行代码的子程序需要修改的几率最低（Lind and Vairavan 1989）。

IBM一项研究发现，最容易出错的是那些超过500行代码的子程序。超过500行后，子程序的出错率和代码行数成正比。在面向对象编程中，一大部分子程序都是访问器子程序（getter），它们都非常短小。任何时候复杂算法总会导致较长的子程序，这种情况下允许长度增加到100到200行。

四、合理的参数


子程序之间的接口是程序中最易出错的地方，Basili和Perrricone所做的一项研究发现程序中39%的错误都是属于内部接口错误。也就是子程序间互相通信时所发生的错误。应该按以下原则处理

1.
按照输入-修改-输出的顺序排列参数。不要随机地按字母顺序排列参数，而应先列出输入参数，然后是即作为输入又作为输出的参数，最后是输出的参数。比如Ada就要专门的关键字in，out。

?





1

2

3

4

procedure InvertMatrix {

    originalMatrix: in
Matrix;

    resultMatrix: out Matrix;

}

2. 如果几个子程序都用了类似的一些参数，应该让这些参数的排列顺序一致。

?





1

2

3

4

5

6

7

8

9

dom = {

    setWidth: function(elem, value) {

        // ...

    },

    setHeight: function(elem, value) {

        // ...

    }

}

3. 使用所有的参数，既然定义了该参数就应该使用它，如果不用它就应该删掉它。

4. 把状态或出错的变量放在后面，状态和那些用于指示发生错误的变量应放在参数表最后。它们只是程序的附属功能且只用于输出的参数。

5. 不要把子程序的参数用于工作变量

?





1

2

3

4

function
process(inputVal) {

    inputVal = inputVal - 10;

    return
inputVal 

}

这段JS代码中，省略了一个变量声明，inputVal很容易让人误解，即是输入又是输出，改为如下

?





1

2

3

4

function
process(inputVal) {

    var
outputVal = inputVal - 10;

    return
outputVal 

}

　　

6. 子程序的参数个数限制在7个以内。鲍勃大叔说的更极端
“最理想的参数数量是零，其次是单参数函数，再次是双参数函数，应尽量避免三参数函数”。心理学研究发现，人类很难记住超过7个单位的信息。这一发现已应用在各个领域。

相关：

Miller
神奇数字7

子程序（过程、函数、方法）

时间： 2024-11-02 01:50:15

子程序设计原则的相关文章

js函数设计原则

一般认为函数指具有返回值的子程序,过程指没有返回值的子程序.C++中把所有子程序成为函数,其实那些返回值为void的 函数在语义上也是过程.函数与过程的区别更多是语义上的区别,而不是语法的区别. 语言纯化论者认为一个函数应该只有一个返回值,这和数学函数一样.即函数只接受输入(参数),通过参数运算返回结果. 除此之外的效果被称为函数的副作用,比如修改全局变量. function sum1(x, y) { return x+y }function sum2(x, y) { alert(x+y) }s

Java 面向对象的设计原则

一. 1.面向对象思想的核心: 封装.继承.多态.   2.面向对象编程的追求: 高内聚低耦合的解决方案: 代码的模块化设计: 3.什么是设计模式: 针对反复出现的问题的经典解决方案,是对特定条件下(上下文)问题的设计方案的经验总结,是前人设计实践经验的精华. 4.面向对象设计原则 是面向对象设计思想(法理精神)的提炼(基本宪法),比面向对象思想的核心要素更具有实操性,比设计模式(各种具体法律条文)更抽象. 5.如何最大限度降低耦合度? 少用类的继承,多用接口隐藏实现细节. 避免使用全局变量.

Java程序员应该了解的10个面向对象设计原则

面向对象设计原则: 是OOPS(Object-Oriented Programming System,面向对象的程序设计系统)编程的核心,但大多数Java程序员追逐像Singleton.Decorator.Observer这样的设计模式,而不重视面向对象的分析和设计.甚至还有经验丰富的Java程序员没有听说过OOPS和SOLID设计原则,他们根本不知道设计原则的好处,也不知道如何依照这些原则来进行编程. 众所周知,Java编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计.查看Ap

Hbase中rowkey设计原则

Hbase中rowkey设计原则 1.热点问题 在某一时间段,有大量的数据同时对一个region进行操作 2.原因 对rowkey的设计不合理 对rowkey的划分不合理 3.解决方式 rowkey是hbase的读写唯一标识 最大长度是64KB. 4.核心原则 设计必须按照业务需求进行设计 5.长度原则 经验:10~100字节可以 官方:16字节,因为操作系统时8字节进行存储 6.散列原则 划分region是按照rowkey的头部进行划分. 有几种方式: )组合字段 id+timestamp )

设计原则之接口隔离原则

segregate   v.隔离 se 蛇  gre green格林  gate门 蛇被格林用门隔离了. 设计原则之接口隔离原则 动机:         客户不应该被强制实现他们不用的方法.应该用多个小的接口代替庞大功能全的接口. 结论:        该原则在代码设计的时候就要考虑.可以使用适配器模式将胖接口隔离. Bad Example:    缺点:         1.如果新增一个robot机器人工人,那么eat方法就是多余的了. // interface segregation pri

设计原则之单一职能原则

设计原则之单一职能原则 动机:         一个职能被考虑成为只有唯一理由去改变,如果我们有两个理由去改变一个类,我们要把这两个功能分成两个类.每个类只控制一个职能,如果在未来有一天我们做某个改变,去改变对应的类就行了. 目标:        一个类应该只有一个被改的理由. Bad Example:缺点:     1.新增一个新的协议将会带来一个新需求,要为每种域序列化内容.     2.内容不一定是string,也会有html等其他形式. // single responsibility 

设计原则之里氏代换原则

设计原则之里氏代换原则 substitute  = replace 替换 sub 下 st石头 i我  tu土 te特别 我用石头替换下土,造了特比坚固的房子 hierarchy  ['harɑk] = level 等级 hi海豹  er儿子  ar are是  ch成龙 海豹儿子的雷霆战机等级是比成龙高 derive [di'raiv]  起源,派生 de德国  rive river河 德国的莱茵河起源于阿尔卑斯山 动机:         当我们创建类的层级(继承),我们继承一些类,创建一些派

设计模式2 面向对象设计原则

面向对象设计原则  原则的目的 面向对象设计原创表  单一职责原则案例 开闭原则 案例 依赖倒转原则 案例 面向对象设计原则  对于面向对象软件系统的设计而言,在支持可维护性的同时,提高系统的可复用性是一个至关重要的问题,如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一.在面向对象设计中,可维护性的复用是以设计原则为基础的.每一个原则都蕴含一些面向对象设计的思想,可以从不同的角度提升一个软件结构的设计水平.  面向对象设计原则为支持可维护性复用而诞生,这些原则蕴含

设计模式——设计模式与设计原则

设计模式--设计模式与设计原则 一.设计模式  1.设计模式简介 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石. 模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再